Nagbibigay ang Firebase Security Rules ng granular, server-enforced mechanism para protektahan ang data sa Firestore, Realtime Database, at Cloud Storage [S1]. Dahil ang mga application na Firebase ay madalas na nakikipag-ugnayan sa mga serbisyong cloud na ito nang direkta mula sa panig ng kliyente, kinakatawan ng mga panuntunang ito ang tanging hadlang na pumipigil sa hindi awtorisadong pag-access sa data ng backend na [S1].
Epekto ng Mga Pahintulot na Panuntunan
Ang mga maling na-configure na panuntunan ay maaaring humantong sa makabuluhang pagkakalantad ng data [S2]. Kung ang mga panuntunan ay nakatakdang maging masyadong mapagpahintulot—halimbawa, gamit ang mga default na setting ng 'test mode' na nagbibigay-daan sa pandaigdigang pag-access—maaaring basahin, baguhin, o tanggalin ng sinumang user na may kaalaman sa project ID ang buong nilalaman ng database [S2]. Nilalampasan nito ang lahat ng hakbang sa seguridad sa panig ng kliyente at maaaring magresulta sa pagkawala ng sensitibong impormasyon ng user o kabuuang pagkagambala sa serbisyo [S2].
Root Cause: Hindi Sapat na Logic ng Awtorisasyon
Ang pangunahing sanhi ng mga kahinaang ito ay karaniwang ang pagkabigo na ipatupad ang mga partikular na kundisyon na naghihigpit sa pag-access batay sa pagkakakilanlan ng user o mga katangian ng mapagkukunan na [S3]. Madalas na iniiwan ng mga developer na aktibo ang mga default na configuration sa mga production environment na hindi nagpapatunay sa request.auth object na [S3]. Nang hindi sinusuri ang request.auth, hindi matukoy ng system ang pagkakaiba sa pagitan ng isang lehitimong na-authenticate na user at isang hindi kilalang humihiling na [S3].
Teknikal na Remediation
Ang pag-secure ng isang Firebase na kapaligiran ay nangangailangan ng paglipat mula sa bukas na pag-access sa isang modelo ng principal-of-least-privilege.
- Ipatupad ang Authentication: Tiyakin na ang lahat ng sensitibong path ay nangangailangan ng wastong session ng user sa pamamagitan ng pagsuri kung ang
request.authobject ay hindi null [S3]. - Ipatupad ang Identity-Based Access: I-configure ang mga panuntunan na naghahambing sa UID ng user (
request.auth.uid) sa isang field sa loob ng dokumento o mismong document ID para matiyak na maa-access lang ng mga user ang sarili nilang data [S3]. - Granular Permission Scoping: Iwasan ang mga global wildcard para sa mga koleksyon. Sa halip, tukuyin ang mga partikular na panuntunan para sa bawat koleksyon at sub-collection upang mabawasan ang potensyal na pag-atake sa ibabaw [S2].
- Pagpapatunay sa pamamagitan ng Emulator Suite: Gamitin ang Firebase Emulator Suite upang subukan ang mga panuntunan sa seguridad nang lokal. Nagbibigay-daan ito para sa pag-verify ng access control logic laban sa iba't ibang persona ng user bago i-deploy sa isang live na kapaligiran [S2].
Paano sinusuri ito ng FixVibe
Kasama na ito sa FixVibe bilang read-only na BaaS scan. Kinukuha ng baas.firebase-rules ang configuration ng Firebase mula sa parehong-origin na mga bundle ng JavaScript, kabilang ang mga modernong initializeApp(...) na mga hugis ng bundle, pagkatapos ay sinusuri ang Realtime Database, Firestore, at Firebase na nabasa nang walang kahilingan-nabasang Storage. Para sa Firestore, sinubukan muna nito ang listahan ng koleksyon ng ugat; kapag naka-block ang listahan, sinisiyasat din nito ang mga karaniwang sensitibong pangalan ng koleksyon gaya ng users, accounts, customers, orders, ZXCVFIXZVIBETOK, messages, admin, at settings. Nag-uulat lamang ito ng mga matagumpay na anonymous na pagbabasa o listahan at hindi nagsusulat, nagtatanggal, o nag-iimbak ng mga nilalaman ng dokumento ng customer.
