// docs / baas security
សុវត្ថិភាព BaaS
វេទិកា Backend-as-a-Service — Supabase, Firebase, Clerk, Auth0 — គ្រប់គ្រងផ្នែកនៃកម្មវិធីដែលឧបករណ៍សរសេរកូដ AI ប៉ះត្រូវដោយប្រុងប្រយ័ត្នតិចបំផុត៖ row-level security, ច្បាប់ storage, ការកំណត់រចនាសម្ព័ន្ធ identity provider និង key ណាមួយដែលត្រូវបញ្ជូនទៅ browser។ ផ្នែកនេះគឺជាបណ្ណាល័យអត្ថបទដែលផ្ដោតលើថាការកំណត់រចនាសម្ព័ន្ធខុសទាំងនោះមើលទៅយ៉ាងណានៅក្នុង production និងរបៀបស្វែងរក និងជួសជុលវា។ អត្ថបទនីមួយៗបញ្ចប់ដោយការ scan មួយចុចលើ deployment ផ្ទាល់ខ្លួនរបស់អ្នក។
// supabase rls scanner
Supabase RLS scanner៖ រកតារាងដែលខ្វះ ឬមាន row-level security ខូច
អ្វីដែលការ scan RLS បែប passive អាចបញ្ជាក់បានពីខាងក្រៅ database, ទម្រង់បួនបែបនៃ RLS ខូចដែលឧបករណ៍សរសេរកូដ AI បង្កើតតាមលំនាំដើម, របៀបដែល FixVibe check
baas.supabase-rlsដំណើរការ និង SQL ពិតប្រាកដដែលត្រូវអនុវត្តនៅពេលរកឃើញ policy ដែលខ្វះ។Scan កម្មវិធីរបស់អ្នកដើម្បីរក RLS ដែលខ្វះ →
// ការបង្ហាញ service role key
Supabase service role key ត្រូវបានបង្ហាញនៅក្នុង JavaScript
អ្វីដែល service role key គឺជា, ហេតុអ្វីវាមិនត្រូវរស់នៅក្នុង browser និងបីវិធីដែលឧបករណ៍សរសេរកូដ AI ដាក់វាដោយចៃដន្យទៅផលិតកម្ម។ រួមមានរូបរាង JWT ដែលកំណត់ key លេចធ្លាយ, runbook ឆ្លើយតបភ្លាមៗ និងរបៀបដែល FixVibe bundle scan រកឃើញវា។
ត្រួតពិនិត្យថា secret ត្រូវបាន ship ក្នុង bundle របស់អ្នកដែរទេ →
// ការពង្រឹង storage
បញ្ជីត្រួតពិនិត្យសុវត្ថិភាព Supabase storage bucket
បញ្ជីត្រួតពិនិត្យផ្ដោត 22 ធាតុសម្រាប់ការពង្រឹង Supabase Storage — ភាពមើលឃើញ bucket, RLS policy លើតារាង
objects, ការផ្ទៀងផ្ទាត់ MIME-type, ការដោះស្រាយ signed-URL, វិធានការប្រឆាំង-enumeration និងអនាម័យប្រតិបត្តិការ។ ធាតុនីមួយៗគឺជាធាតុមួយដែលអ្នកអាចបញ្ចប់ក្នុង 5-15 នាទី។Scan bucket សាធារណៈ និង storage ដែលអាចរាយ anon →
// firebase rules scanner
Firebase rules scanner៖ រកច្បាប់ Firestore, Realtime Database និង Storage បើកចំហ
របៀបដែល Firebase rules scanner ដំណើរការពីខាងក្រៅ, លំនាំ test-mode ដែលឧបករណ៍ AI បង្កើត, សេវាកម្ម Firebase បីដែលនីមួយៗត្រូវការការត្រួតពិនិត្យច្បាប់ផ្ទាល់របស់វា (Firestore, Realtime Database, Storage) និងអ្វីដែលការ scan អាចបញ្ជាក់បានដោយគ្មាន credential។
ត្រួតពិនិត្យច្បាប់អាន/សរសេរបើកចំហ →
// ការពន្យល់ syntax ច្បាប់
Firebase allow read, write: if true ពន្យល់
អ្វីដែលច្បាប់
allow read, write: if true;ពិតជាធ្វើ, ហេតុអ្វី Firebase ship វាជាលំនាំដើម test-mode, ឥរិយាបថពិតប្រាកដដែលអ្នកវាយប្រហារឃើញ និងវិធីបួនដើម្បីជំនួសវាជាមួយច្បាប់ដែលមានសុវត្ថិភាពផលិតកម្ម។ រួមមាន query ត្រួតពិនិត្យ copy-paste និងផែនការដោះស្រាយ 5 ជំហាន។Scan URL ផលិតកម្មរបស់អ្នក →
// ការពង្រឹង clerk
បញ្ជីត្រួតពិនិត្យសុវត្ថិភាព Clerk
បញ្ជីត្រួតពិនិត្យ 20 ធាតុសម្រាប់ការពង្រឹងការរួមបញ្ចូល Clerk — អនាម័យ environment-key, ការកំណត់ session, ការផ្ទៀងផ្ទាត់ webhook, សិទ្ធិ organization, scope JWT-template និងការតាមដានប្រតិបត្តិការ។ ធាតុមុនការដាក់ឱ្យដំណើរការ និងបន្តដែលដាក់ជាក្រុមតាមផ្នែក។
ត្រួតពិនិត្យការកំណត់រចនាសម្ព័ន្ធ auth/session ខុស →
// ការពង្រឹង auth0
បញ្ជីត្រួតពិនិត្យសុវត្ថិភាព Auth0
ការត្រួតពិនិត្យ Auth0 22 ធាតុដែលគ្របដណ្ដប់ប្រភេទកម្មវិធី និង grant, allowlist callback / logout URL, ការបង្វិល refresh-token, សុវត្ថិភាព custom-action, RBAC និង resource server, ការរកឃើញភាពមិនធម្មតា និងការតាមដាន log tenant។ ចាប់ធាតុដែលកម្មវិធី SaaS ដែលបង្កើតដោយ AI បាត់បន្តបន្ទាប់។
ត្រួតពិនិត្យការបង្ហាញ identity-provider →
// scanner ឆ័ត្រ
BaaS misconfiguration scanner៖ រកផ្លូវទិន្នន័យសាធារណៈនៅទូទាំង Supabase, Firebase, Clerk និង Auth0
ហេតុអ្វី BaaS provider បរាជ័យសុវត្ថិភាពតាមរូបរាងដូចគ្នា, ថ្នាក់ការកំណត់រចនាសម្ព័ន្ធខុសប្រាំដែលរាល់កម្មវិធីដែលគាំទ្រដោយ BaaS ត្រូវការត្រួតពិនិត្យ, របៀបដែលឆ័ត្រ FixVibe BaaS scan ដំណើរការនៅទូទាំង provider ទាំងបួន, ការប្រៀបធៀបជំហររបស់អ្វីដែល scanner នីមួយៗអាចបញ្ជាក់ និងការប្រៀបធៀបស្មោះត្រង់ទៅ Burp, ZAP និងឧបករណ៍ SAST។
រកផ្លូវទិន្នន័យសាធារណៈមុនពេលអ្នកប្រើ →
អ្វីដែលនឹងមកដល់ខាងមុខ
អត្ថបទដែលផ្ដោតលើ BaaS បន្ថែមនឹងមកដល់នៅទីនេះនៅពេល scan engine របស់ FixVibe ពង្រីកការគ្របដណ្ដប់របស់វា។ changelog របស់ scan engine កត់ត្រាការរកឃើញថ្មីៗទាំងអស់ — ជាវវាសម្រាប់បញ្ជីបន្តនៃអ្វីដែល FixVibe ឥឡូវនេះអាចបញ្ជាក់បានពីខាងក្រៅ។