Firebase

Live audit of your Firebase project — security rules, App Check enforcement, auth policy, and storage exposure. Catches the misconfigurations a repo scan can't see.

Available on the Studio tier. Read-only access via Google OAuth — we never mutate your Firebase project.

Why this matters

The two failure modes that hurt fastest on a Firebase project both live in the console, not the repo: a Firestore rule left at allow read, write: if true from the prototype phase, and a Storage bucket open to the same wildcard. AI-built apps land both regularly because the scaffolds Firebase ships start permissive. Repo scans can’t see either — the rules live on Firebase’s side. So we read them.

Connect Firebase

01

Open project settings.

From the project page, click the gear icon → Connected platforms → Firebase.

02

Authorise via Google OAuth.

You’re redirected to Google’s standard consent screen. We request one Firebase-management scope: firebase.readonly (plus openid + email for identity). You can review the scope list on the consent page; we never request cloud-platform.read-only or any broader scope.

03

Pick the Firebase project.

Your accessible Firebase projects appear in a picker. Choose the one this PulseLight project ships against. If your account has multiple, only the chosen project is read by the audit.

04

First scan.

The next scan includes the Firebase Connected Check findings alongside repo findings — rolled up into the Secure pillar.

What we verify

  • Firestore security rules — CONN-FIREBASE-RULES-001

    We read your Firestore rules and flag the classic prototype pattern: allow read, write: if true (or its variants). This is the single most-common data-leak failure on Firebase apps.

  • Realtime Database rules — CONN-FIREBASE-RULES-002

    Same audit shape for RTDB — a separate rule namespace that’s easy to forget about. We check .read and .write at the database root for permissive defaults.

  • Storage bucket rules — CONN-FIREBASE-STORAGE-001

    Firebase Storage uses the same allow grammar. We confirm no path is open to anonymous reads or writes.

  • App Check enforcement — CONN-FIREBASE-APPCHECK-001

    App Check binds calls to your project to verified app instances. Without it, anyone can hit your APIs directly with your public Firebase config. We confirm App Check is enforced on at least one of Firestore / Storage / RTDB.

  • Auth provider policy — CONN-FIREBASE-AUTH-001

    We read your Firebase Auth tenant config and flag the common gaps: email-password enabled without minimum password length, no MFA option offered, sign-up open with no domain restriction on internal-only apps.

Privacy + scope

We store a Google refresh token, encrypted at rest with KMS envelope encryption. The token is decrypted only at scan time and is used exclusively against the Firebase Management API. We never read user records, never modify rules, never deploy Cloud Functions, never bill against your project. Revoke access from your Google account permissions page at any time — the next scan reports the integration as revoked.