BaaS-ის არასწორი კონფიგურაციის სკანერი: იპოვეთ საჯარო მონაცემთა გზები მომხმარებლებზე ადრე

რატომ აქვს BaaS-ის არასწორ კონფიგურაციებს განმეორებადი ფორმა

ყოველი BaaS-პლატფორმა იყენებს ერთსა და იმავე არქიტექტურას: მართულ backend-ს თხელი კლიენტ-SDK-ით, რომელიც მას ბრაუზერიდან ესაუბრება. ბრაუზერისთვის-მიმართულ კლიენტს სჭირდება რაიმე სერთიფიკატი — anon-გასაღები, გამოსაქვეყნებელი გასაღები, Firebase-პროექტის ID — რათა საკუთარი თავი backend-ს გააცნოს. ეს სერთიფიკატი მიზანმიმართულად საჯაროა; არქიტექტურის უსაფრთხოება ეფუძნება პლატფორმის-დონის წვდომის კონტროლს (RLS, წესები, დაშვების სიები), რომელიც თავის საქმეს აკეთებს.

AI-კოდირების ხელსაწყოები აშენებენ ამ არქიტექტურის თავზე პლატფორმის-კონტროლის ფენის გათავისების გარეშე. ისინი სწორად აკავშირებენ კლიენტ-SDK-ს, იღებენ პლატფორმის ნაგულისხმევ დასაშვებ წესებს (რომელიც არსებობს ტუტორიალისთვის-მეგობრულობისთვის) და აგზავნიან. განმეორებადი ფორმა არის: საჯარო სერთიფიკატი + დასაშვები ნაგულისხმევი წესი + გამოტოვებული გადაფარვა = მონაცემთა გამოვლენა. ხუთი არასწორი კონფიგურაციის კლასი ქვემოთ ყველა არის ამ ფორმის ვარიანტი.

ხუთი განმეორებადი არასწორი კონფიგურაციის კლასი

ეს ჩნდება ყოველ BaaS-პროვაიდერზე. სრული სკანი ფარავს ხუთივეს ყოველი გამოყენებული პროვაიდერის წინააღმდეგ:

კლასი 1: არასწორი გასაღები ბრაუზერის ბანდლში

ბრაუზერი აგზავნის secret/admin-გასაღებს (Supabase service_role, Firebase Admin SDK კერძო გასაღები, Clerk sk_*, Auth0-ის კლიენტის საიდუმლო) საჯარო/anon-ეკვივალენტის ნაცვლად. ბრაუზერი ხდება შეუზღუდავი ადმინ-კლიენტი. გაშუქებულია FixVibe-ის ბანდლ-საიდუმლოების შემოწმებით.

კლასი 2: წვდომის-კონტროლის ფენა გათიშულია ან დასაშვები

RLS გათიშულია, Firebase-ის წესები არის if true, Auth0-ის callback-სია wildcard-ულია. ბრაუზერში სერთიფიკატი სწორია — მაგრამ პლატფორმის-დონის საზღვარი, რომელიც გათვლილი იყო მის შესაკავებლად, თავის საქმეს არ აკეთებს.

კლასი 3: ანონიმური წაკითხვები სენსიტიური რესურსების

Anon-წაკითხვადი Firestore-კოლექციები, anon-listable Supabase storage-ბაკეტები, anon-მისადგომი Auth0 management API. სკანი კითხულობს: „სერთიფიკატის გარეშე, რას წავიკითხავ?"

კლასი 4: ტესტ-რეჟიმის არტეფაქტები პროდუქციაში

ტესტ-გასაღებები (pk_test_*, sb_test_*) პროდუქციის დეპლოიში; dev-რეჟიმის Firebase-აპები მისადგომი ცოცხალი დომენიდან; ტესტ-ტენანტი Auth0-აპლიკაციები სუსტი პარამეტრებით პროდუქციასთან შედარებით. სკანი ადარებს გაშვების გასაღებებს მოსალოდნელ პროდუქციის პრეფიქსების წინააღმდეგ.

კლასი 5: Webhook-ხელმოწერის ვერიფიკაცია გამოტოვებულია

Clerk-webhook-ები, Stripe-webhook-ები, Supabase-webhook-ები ყველა ხელს აწერენ თავიანთ payload-ებს. ჰენდლერი, რომელიც ხელმოწერას არ ამოწმებს, არის მონაცემთა ბაზის-ჩაწერის პრიმიტივი ნებისმიერი თავდამსხმელისთვის, რომელიც URL-ს გამოიცნობს. აღმოჩენილია პასუხის ფორმით — არახელმოწერილი მოთხოვნა, რომელიც 200-ს იღებს, ნიშნავს, რომ ვერიფიკაცია გამოტოვებულია.

როგორ მუშაობს FixVibe-ის ერთიანი BaaS-სკანი

FixVibe-ის BaaS-ფაზა მუშაობს სამ ეტაპად, თითოეული გამოყოფილ აღმოჩენებს ქმნის:

1. <strong>Stage 1 — provider fingerprinting.</strong> The scanner crawls the deployed app, parses every JavaScript chunk, and identifies which BaaS providers the app uses. Each provider has a distinctive runtime signature: Supabase uses <code>*.supabase.co</code>; Firebase uses <code>firebase.initializeApp({ projectId: ... })</code>; Clerk uses <code>pk_*</code> keys with a known prefix; Auth0 uses <code>clientId</code> and <code>domain</code>. The scanner records which providers are present and extracts the project identifiers.
2. ეტაპი 2 — პროვაიდერ-სპეციფიკური შემოწმებები. ყოველი აღმოჩენილი პროვაიდერისთვის, სკანერი უშვებს პროვაიდერ-სპეციფიკურ შემოწმებას: baas.supabase-rls ამოწმებს PostgREST-ს; baas.firebase-rules ამოწმებს Firestore + RTDB + Storage-ს; baas.clerk-auth0 დაამოწმებს ბანდლირებული გასაღებების პრეფიქსს; ბანდლ-საიდუმლოების შემოწმება ადასტურებს, რომ არც ერთი service-დონის სერთიფიკატი არ გაჟონა. ყოველი შემოწმება მუშაობს დამოუკიდებლად — Supabase-აღმოჩენა არ ბლოკავს Firebase-სკანს.
3. ეტაპი 3 — ჯვარედინი-პროვაიდერის კორელაცია. სკანერი ჯვარედინად მიუთითებს აღმოჩენებზე. გამოვლენილი Supabase service-role გასაღები გამოტოვებულ RLS-თან ერთად უფრო მძიმეა ვიდრე ნებისმიერი აღმოჩენა ცალკე — რეპორტი ამას წინ წამოწევს. რამდენიმე ვინაობის პროვაიდერი (Clerk + Auth0 + კასტომ auth) იმავე აპში არის სტრუქტურული აღმოჩენა, რომელიც მიმოხილვისთვის არის მონიშნული.

ყოველი შემოწმება პასიურია: მაქსიმუმ ერთი ანონიმური წაკითხვა რესურსზე, პასუხის ფორმის ჩაწერით, მაგრამ მწკრივების შინაარსი არასოდეს არ აქცევს ფურცლებად ან ინახება. ჩაწერისა და ცვლის შემოწმებები გადახდელია ვერიფიცირებული დომენის მფლობელობის უკან — ისინი არასოდეს ეშვება არავერიფიცირებული მიზნების წინააღმდეგ.

რას იპოვის სკანერი პროვაიდერზე

ყოველ BaaS-პროვაიდერს აქვს განსხვავებული ზედაპირი და განსხვავებული სკან-სტრატეგია. აი, რა არის გაშუქებული:

• Supabase: გამოტოვებული RLS ცხრილებზე, anon-listable storage-ბაკეტები, გამოვლენილი service_role JWT ან sb_secret_* გასაღები ბანდლში, გამოვლენილი სქემები ანონიმური OpenAPI-ჩამოთვლით. ნახეთ Supabase RLS სკანერი და Storage-ის სია.
• Firebase: if true წესები Firestore-ზე, Realtime Database-ზე და Cloud Storage-ზე; anon-listable Storage-ბაკეტები; გამოტოვებული App Check-ის აღსრულება. ნახეთ Firebase rules სკანერი და If-true წესის ახსნა.
• Clerk: ბანდლირებული sk_* secret-გასაღებები, pk_test_* პროდუქციაში, გამოტოვებული webhook-ხელმოწერის ვერიფიკაცია, wildcard დაშვებული origin-ები. ნახეთ Clerk-ის სია.
• Auth0: ბანდლირებული კლიენტის საიდუმლოები, ჩართული Implicit-გრანტი, wildcard callback / logout URL-ები, გამოტოვებული PKCE SPA-ებზე. ნახეთ Auth0-ის სია.

როგორ ედარება BaaS-სკანერი ზოგად DAST- და SAST-ხელსაწყოებს

BaaS-აზრიანი სკანერი აკეთებს კონკრეტულ სამუშაოს, რომელსაც სხვა ხელსაწყოები არ აკეთებენ. შედარება:

პატიოსანი სკოპი: რას არ ცვლის ეს სკანერი

BaaS-აზრიანი DAST-სკანერი არის ფოკუსირებული ხელსაწყო, არა სრული უსაფრთხოების პროგრამა. ის არ:

• ცვლის SAST-ს ან SCA-ს. სტატიკური ანალიზი პოულობს დამოკიდებულების CVE-ებს (Snyk, Semgrep) და კოდის-დონის მოწყვლადობებს (SonarQube), რომელთა აღმოჩენაც DAST-სკანერს არ შეუძლია. გაუშვით ორივე.
• ცვლის ხელით პენტესტინგს. ადამიანი პენტესტერი პოულობს ბიზნეს-ლოგიკის ხარვეზებს, ავტორიზაციის edge case-ებს და ჯაჭვური მოწყვლადობებს, რომელთა აღმოჩენაც ვერც ერთ სკანერს ვერ შეუძლია. დაიქირავეთ პენტესტერი მნიშვნელოვან გაშვებამდე ან შესაბამისობის აუდიტამდე.
• აუდიტს უკეთებს თქვენს კოდს ან რეპოს საიდუმლოებზე git-ის ისტორიაში. ბანდლ-საიდუმლოების შემოწმება ფარავს იმას, რაც ამჟამად დეპლოიდია, არა იმას, რაც ისტორიულად commit-დებოდა. გამოიყენეთ git-secrets ან gitleaks რეპო-ჰიგიენისთვის.
• ფარავს არა-BaaS backend-სერვისებს. თუ თქვენი აპი იყენებს კასტომ backend-ს (Express, Rails, Django, FastAPI), FixVibe სკანერავს მის HTTP-ზედაპირს, მაგრამ არ ამოწმებს მის უკან არსებულ მონაცემთა ბაზას ან ინფრასტრუქტურას. ეს არის ზოგადი DAST + SAST ტერიტორია.

ხშირად დასმული შეკითხვები

შემდეგი ნაბიჯები

გაუშვით უფასო FixVibe-სკანი თქვენი პროდუქციის URL-ის წინააღმდეგ — BaaS-ფაზის შემოწმებები იშვება ყოველ გეგმაში, უფასო ტარიფის ჩათვლით. პროვაიდერ-სპეციფიკური ღრმა მონაცემებისთვის, ცალკეული სტატიები ამ განყოფილებაში ფარავს ყოველ პროვაიდერს დეტალურად: Supabase RLS, Supabase service-key-ის გამოვლენა, Supabase storage, Firebase rules, Firebase if-true, Clerk და Auth0.