// docs / baas security / firebase if-true explainer

Firebase allow read, write: if true ពន្យល់៖ តើវាធ្វើអ្វី និងរបៀបជួសជុលវា

Q: តើភាពខុសគ្នារវាង if true និង if request.auth != null គឺជាអ្វី?

if true អនុញ្ញាតការចូលប្រើ anonymous — នរណាក៏ដោយនៅលើអ៊ីនធឺណិត។ if request.auth != null ត្រូវការអ្នកប្រើដែលចូលណាមួយ ដែលល្អជាង តែនៅតែខុស៖ អ្នកប្រើណាមួយនៃកម្មវិធីរបស់អ្នកអាចអានទិន្នន័យអ្នកប្រើផ្សេងទៀតគ្រប់គ្នា។ ច្បាប់ផលិតកម្មត្រូវ scope ទៅអ្នកប្រើ ឬ org ជាក់លាក់តាមរយៈ request.auth.uid == resource.data.owner_uid ឬស្រដៀង។

Q: ចុះបើកម្មវិធីរបស់ខ្ញុំជាការអានសាធារណៈពិតៗ (blog, កាតាឡុកផលិតផល)?

នោះសរសេរ allow read: if true; allow write: if false; ច្បាស់នៅលើ collection សាធារណៈតែប៉ុណ្ណោះ — មិនមែននៅលើរាល់ collection នៅក្នុង database របស់អ្នកឡើយ។ ប្រើ clause match ដាច់ដោយឡែកក្នុង collection នីមួយៗ និងមិនដែលប្រើ wildcard '{'document=**'}' recursive នៅលើច្បាប់សរសេរបានឡើយ។

<code>allow read, write: if true;</code> គឺជាការកំណត់រចនាសម្ព័ន្ធខុសរបស់ Firebase ដែលរីករាលដាលបំផុតនៅក្នុងផលិតកម្ម។ វាគឺជាលំនាំដើម test-mode ដែល Firebase Console ស្នើនៅពេលអ្នកបង្កើត database ថ្មី, ច្បាប់ដែលឧបករណ៍សរសេរកូដ AI បង្កើតឡើងវិញពី documentation និងច្បាប់ដែលបើក Firestore database ទាំងមូលរបស់អ្នកដល់នរណាក៏ដោយនៅលើអ៊ីនធឺណិត។ អត្ថបទនេះពន្យល់ syntax យ៉ាងច្បាស់លាស់, បង្ហាញអ្វីដែលអ្នកវាយប្រហារឃើញនៅពេលច្បាប់នេះកំពុងដំណើរការ និងផ្ដល់អ្នកនូវការជំនួសបួនដែលតឹងជាងគ្នាបន្តិចម្ដងៗដែលសមនឹងករណីប្រើផ្សេងគ្នា។

Syntax, បន្ទាត់ដោយបន្ទាត់

ឯកសារច្បាប់ Firestore test-mode ពេញលេញគឺ 6 បន្ទាត់៖

firebase

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

Decoded៖

rules_version = '2'; ជ្រើសរើស rules engine v2 (បច្ចុប្បន្ន)។ ច្បាប់ v1 ចាស់ត្រូវបានបោះបង់។
service cloud.firestore កំណត់ scope block ទៅ Firestore។ Realtime Database ប្រើ syntax JSON ផ្សេង; Cloud Storage ប្រើ service firebase.storage។
match /databases/{database}/documents ចង database ពិសេស (default) (ភាគច្រើន project មានតែមួយ)។
match /{document=**} គឺជា wildcard recursive។ ** ត្រូវនឹងផ្លូវណាមួយនៃជម្រៅណាមួយ។ រួមជាមួយ {document}, នេះចាប់រាល់ឯកសារនៅក្នុងរាល់ collection — clause match តែមួយដែលគ្រប់គ្រង database ទាំងមូល។
allow read, write: if true; គឺជា body ច្បាប់។ ទាំង read និង write ត្រូវបានអនុញ្ញាត; លក្ខខណ្ឌ if true គឺ, ពិតជា, ពិតជានិច្ច។ read គ្របដណ្ដប់ប្រតិបត្តិការ get និង list; write គ្របដណ្ដប់ create, update និង delete។

ផលប្រសិទ្ធភាពសុទ្ធ៖ client ណាមួយដែលមាន Firebase project ID និង SDK ត្រឹមត្រូវអាចអាន ឬសរសេរឯកសារណាមួយនៅក្នុង collection ណាមួយ។ Authentication មិនត្រូវការ។ ដែនកំណត់អត្រាមិនត្រូវបានអនុវត្ត។

ហេតុអ្វី Firebase ship នេះជាលំនាំដើម

Firebase ចង់ឱ្យអ្នកសរសេរកូដក្នុង 30 វិនាទីដំបូងបន្ទាប់ពីការបង្កើត project។ ជម្រើស — ការធ្វើឱ្យអ្នកសរសេរច្បាប់ត្រឹមត្រូវមុនពេលការអាន ឬសរសេរណាមួយដំណើរការ — នឹងបិទ onboarding។ ដូច្នេះ Console ផ្ដល់ជម្រើសពីរនៅពេលអ្នកបង្កើត database៖ Production mode (បដិសេធគ្រប់យ៉ាង អ្នកសរសេរច្បាប់) ឬ Test mode (អនុញ្ញាតគ្រប់យ៉ាងសម្រាប់ 30 ថ្ងៃ)។ អ្នកអភិវឌ្ឍន៍ភាគច្រើនចុច test mode បន្ទាប់មកភ្លេចត្រឡប់មកវិញ។ Project ចាស់មាន timer 30 ថ្ងៃ; project បច្ចុប្បន្នមានច្បាប់ if true គ្មានកំណត់ដោយគ្មានការផុតកំណត់ស្វ័យប្រវត្តិ។

បញ្ហារចនាសម្ព័ន្ធ៖ ឧបករណ៍សរសេរកូដ AI បង្វឹកលើ documentation, tutorial និងចម្លើយ Stack Overflow ដែលបង្ហាញច្បាប់ test-mode។ នៅពេលអ្នកសួរ Cursor ឬ Claude Code "តើខ្ញុំ setup Firebase ដូចម្ដេច," ចម្លើយជារឿយៗរួមមាន block allow read, write: if true ច្បាស់ៗហាក់ដូចជាវាជាច្បាប់ផលិតកម្ម។ AI មិនដឹង — និងមិនត្រូវបានជំរុញឱ្យដឹង — ថាច្បាប់នេះមិនមានសុវត្ថិភាពសម្រាប់ផលិតកម្ម។

អ្វីដែលអ្នកវាយប្រហារឃើញ

ជាក់ស្ដែង, អ្នកវាយប្រហារដែលដឹង Firebase project ID របស់អ្នក (ស្រង់បានពី bundle កម្មវិធីដែលបាន deploy ណាមួយក្នុង 30 វិនាទី) និងដំណើរការដូចខាងក្រោមអាចរាយរាល់ឯកសារនៅក្នុងរាល់ collection៖

Request curl មិនបាន authenticate តែមួយគឺគ្រប់គ្រាន់ដើម្បី enumerate រាល់ collection។ សូមមើល block ដែលបង្ហាញពន្លឺខាងក្រោម។

bash

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

Response គឺជាបញ្ជីពេញលេញនៃ collection កម្រិតខ្ពស់។ សម្រាប់ collection នីមួយៗ, request ទីពីរត្រឡប់ឯកសារ។ គ្មានដែនកំណត់អត្រានៅលើផ្លូវនេះព្រោះច្បាប់ if true ទទួលយក traffic anonymous។ យើងបានឃើញ Firebase database ជាមួយឯកសាររាប់លាន enumerated ក្នុងរយៈពេលក្រោម 1 ម៉ោង។

នៅផ្លូវសរសេរ៖ POST តែមួយជាមួយ {fields} បង្កើតឯកសារថ្មី។ អ្នកវាយប្រហារអាចបំពុល collection របស់អ្នកជាមួយសម្រាម, ខូចទ្រង់ទ្រាយទំព័រដែលប្រឈមមុខអ្នកប្រើដែលអាន Firestore ឬប្រើ database របស់អ្នកជា message broker ឥតគិតថ្លៃ — វិក្កយបត្រការប្រើប្រាស់របស់អ្នកកើនឡើង, អ្នកស៊ើបអង្កេត, វិក្កយបត្រពន្យល់បញ្ហា។

ការជំនួសសុវត្ថិភាពផលិតកម្មបួន

ជ្រើសរើសការជំនួសដែលត្រូវនឹង model ទិន្នន័យកម្មវិធីរបស់អ្នក។ ទាំងបួនសន្មត់ថាអ្នកមាន authentication អ្នកប្រើ (Firebase Auth ឬ provider ណាមួយដែលចេញ Firebase ID token)៖

ជម្រើសទី 1៖ ឯកសារជាកម្មសិទ្ធិអ្នកប្រើ

លំនាំ SaaS សាមញ្ញបំផុត។ ឯកសាររស់នៅក្រោម /users/{userId}/... ហើយតែម្ចាស់អាចប៉ះវា។ match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

firebase

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

ជម្រើសទី 2៖ Field ម្ចាស់នៅរាល់ឯកសារ

នៅពេលឯកសាររស់នៅក្នុង collection សំប៉ែត (មិន nested ក្រោម user ID), រក្សា field owner_uid និងពិនិត្យវា។ match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

firebase

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

ជម្រើសទី 3៖ ការដាច់ស្រយាល org Multi-tenant

សម្រាប់ B2B SaaS ជាមួយទិន្នន័យ scope តាម org។ រក្សា field org_id លើរាល់ឯកសារ និងពិនិត្យវាប្រឆាំងនឹង custom claim របស់អ្នកប្រើ។ allow read, write: if request.auth.token.org_id == resource.data.org_id;។ ត្រូវការការកំណត់ custom claim ក្នុងពេលចុះឈ្មោះតាមរយៈ Firebase Admin SDK។

firebase

allow read, write: if request.auth.token.org_id == resource.data.org_id;

ជម្រើសទី 4៖ មាតិកាសាធារណៈអានតែប៉ុណ្ណោះ

សម្រាប់មាតិកា marketing, profile សាធារណៈ, កាតាឡុកផលិតផល — អ្វីៗដែលជាការអានសាធារណៈពិតៗ តែការសរសេរសម្រាប់តែ admin។ match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }។ Custom claim admin ត្រូវបានកំណត់នៅលើគណនី admin តែប៉ុណ្ណោះ។

firebase

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

Query ត្រួតពិនិត្យរហ័ស

មុនពេលជួសជុល, ត្រួតពិនិត្យថា if true ពិតជាកំពុងដំណើរការឬអត់។ បើក Firebase Console → Firestore → Rules និងស្វែងរក if true។ បើអ្នករកឃើញវានៅកន្លែងណាមួយក្រៅ comment, អ្នកមាន finding ច្បាប់បើកចំហ។ Rules simulator នៅក្នុង UI ដូចគ្នាអនុញ្ញាតឱ្យអ្នកលេង request របស់អ្នកវាយប្រហារឡើងវិញនៅក្នុងមូលដ្ឋាន — បិទភ្ជាប់ GET /users/somebody anonymous និងបញ្ជាក់ថា simulator ត្រឡប់ Allowed។

ការបញ្ជាក់ខាងក្រៅ៖ ដំណើរការ FixVibe scan ប្រឆាំងនឹង URL ផលិតកម្មរបស់អ្នក។ ការត្រួតពិនិត្យ baas.firebase-rules ត្រួតពិនិត្យច្បាប់ Firestore, Realtime Database និង Storage របស់អ្នក និងរាយការណ៍ finding ដូចគ្នាដែលអ្នកវាយប្រហារនឹងរកឃើញ — ឯករាជ្យពីអ្វីដែល Firebase Console បង្ហាញ។

សំណួរសួរញឹកញាប់

តើភាពខុសគ្នារវាង <code>if true</code> និង <code>if request.auth != null</code> គឺជាអ្វី?

if true អនុញ្ញាតការចូលប្រើ anonymous — នរណាក៏ដោយនៅលើអ៊ីនធឺណិត។ if request.auth != null ត្រូវការអ្នកប្រើដែលចូលណាមួយ ដែលល្អជាង តែនៅតែខុស៖ អ្នកប្រើណាមួយនៃកម្មវិធីរបស់អ្នកអាចអានទិន្នន័យអ្នកប្រើផ្សេងទៀតគ្រប់គ្នា។ ច្បាប់ផលិតកម្មត្រូវ scope ទៅអ្នកប្រើ ឬ org ជាក់លាក់តាមរយៈ request.auth.uid == resource.data.owner_uid ឬស្រដៀង។

តើ Firebase ផុតកំណត់ច្បាប់ <code>if true</code> ដោយស្វ័យប្រវត្តិដែរទេ?

Project ចាស់ (មុនឆ្នាំ 2023) មាន timer 30 ថ្ងៃដែលប្ដូរច្បាប់ if true ទៅ if false។ Project បច្ចុប្បន្នមិនមាន — ច្បាប់នៅជារៀងរហូតរហូតដល់ត្រូវបានជំនួសដោយដៃ។ បើអ្នកបង្កើត project របស់អ្នកមុនឆ្នាំ 2023 ហើយច្បាប់របស់អ្នកមើលទៅល្អ, ពិនិត្យពីរដង៖ timer អាចមានរួចរាល់ហើយប្ដូរវាទៅ if false, ដែលរារាំងកម្មវិធីផ្ទាល់ខ្លួនរបស់អ្នក។

តើខ្ញុំអាចប្រើការត្រួតពិនិត្យ timestamp អនាគតជាសុវត្ថិភាពទេ?

ទេ — លក្ខខណ្ឌ timestamp មិនមែនជាការគ្រប់គ្រងសុវត្ថិភាពឡើយ។ វាផុតកំណត់ច្បាប់បើកនៅថ្ងៃអនាគត ដែលមានន័យថារហូតដល់ថ្ងៃនោះអ្នកវាយប្រហារមានការចូលប្រើពេញលេញ។ ហើយអ្នកនឹងភ្លេចថ្ងៃ។ ជំនួស if true ជាមួយច្បាប់ scope តាម auth មិនមែនច្បាប់ដែលមានព្រំដែនពេលឡើយ។

ចុះបើកម្មវិធីរបស់ខ្ញុំជាការអានសាធារណៈពិតៗ (blog, កាតាឡុកផលិតផល)?

នោះសរសេរ allow read: if true; allow write: if false; ច្បាស់នៅលើ collection សាធារណៈតែប៉ុណ្ណោះ — មិនមែននៅលើរាល់ collection នៅក្នុង database របស់អ្នកឡើយ។ ប្រើ clause match ដាច់ដោយឡែកក្នុង collection នីមួយៗ និងមិនដែលប្រើ wildcard {document=**} recursive នៅលើច្បាប់សរសេរបានឡើយ។

ជំហានបន្ទាប់

ដំណើរការ FixVibe scan ប្រឆាំងនឹង URL ផលិតកម្មរបស់អ្នក — ការត្រួតពិនិត្យ baas.firebase-rules បញ្ជាក់ថា if true បច្ចុប្បន្នអាចកេងប្រវ័ញ្ចបានពីអ៊ីនធឺណិតសាធារណៈឬអត់។ សម្រាប់មេកានិច scanner និងការរកឃើញស្របគ្នាសម្រាប់ Realtime Database និង Storage, សូមមើល Firebase rules scanner។ សម្រាប់ថ្នាក់ស្មើគ្នានៃការកំណត់រចនាសម្ព័ន្ធខុសនៅលើ Supabase, សូមអាន Supabase RLS scanner។