Firebase and Supabase Misconfiguration Hunting: BaaS Exposure in CTEM and ASM

TL;DR

Firebase and Supabase move the security boundary out of a server you control and into rules, policies, and bucket ACLs. The API key in a web app's JavaScript bundle is public by design — so when Firestore rules, Realtime Database permissions, or Postgres Row Level Security are permissive, that public key becomes an unauthenticated bulk data export. This guide covers how BaaS misconfigurations get found and abused, what telemetry actually reveals them, and how Trusteed CTEM treats Firebase and Supabase projects as first-class attack surface assets: continuously inventoried, tested through a dedicated API surface worker, and validated before anything reaches the SOC queue.

• The core pattern: public client credential + missing authorization = data breach with no exploit payload.
• The hard part: there is no host to port-scan. The asset is a configuration plane plus an auto-generated data API.
• The fix: continuous discovery, authorization testing, exploitability validation, and a workflow that stops configuration drift from becoming permanent exposure.

What is Firebase and Supabase misconfiguration hunting?

It is the practice of discovering, testing, and remediating insecure configurations in Backend-as-a-Service platforms where the client holds a credential by design and the authorization decision happens in server-side policy — not in the code you deploy.

Both platforms are well-engineered products. The problem is architectural: they make it trivial to ship a working app, and just as easy to ship one with the authorization layer wide open, because a permissive rule looks completely healthy in a browser.

Firebase (Google) exposes several distinct trust boundaries:

• Cloud Firestore — document database governed by security rules evaluated per request.
• Realtime Database — JSON tree governed by read/write rules, with a long tail of legacy projects on permissive defaults.
• Cloud Storage — object buckets governed by Storage rules, including whether clients may list objects.
• Cloud Functions — callable and HTTP endpoints that may be invokable without authentication.
• Identity Platform / Firebase Auth — sign-up and sign-in behavior, including anonymous account creation.
• Hosting and custom domains — including dangling domains that can be reclaimed.

Supabase exposes a layered surface of its own:

• PostgREST auto-generated API — every table in the exposed schema becomes an HTTP endpoint unless Row Level Security (RLS) blocks it.
• RLS policies — the real authorization layer, and the most common failure point.
• Supabase Storage — buckets with public/private flags and listing behavior.
• Edge Functions — Deno functions with a JWT verification toggle.
• Auth (GoTrue) — signup, email confirmation, and session handling.
• Database functions (rpc/) — SECURITY DEFINER functions can bypass RLS by design.

What separates this from traditional application security is that you do not need to exploit anything. There is no memory corruption, no injection string, no bypass technique. You present a public key to a public endpoint and the platform answers honestly. A BaaS misconfiguration is not a classic vulnerability — it is an authorization policy that says yes.

Why it matters now

Three trends pushed BaaS misconfiguration from a niche finding to a board-level exposure category.

Frontend-first and AI-assisted development. Teams — and increasingly AI coding assistants — scaffold a working frontend against a BaaS backend in hours. The generated code correctly wires up reads and writes. It rarely produces a complete authorization model, because an incomplete model still demos perfectly.

Single-failure blast radius. A misconfigured Firestore collection or an RLS-free Postgres table is not a foothold requiring lateral movement. It is the data. One permissive read path can expose every user record, order, message, or health document in the project — structured, queryable, and exportable with curl.

Shadow projects outside inventory. Marketing microsites, contractor builds, prototypes, acquired products, and internal tools all spawn Firebase and Supabase projects. They use platform-default hostnames (*.web.app, *.firebaseapp.com, *.supabase.co), so they never appear in an IP-based scan. Security teams often learn about them from a breach notification rather than an asset inventory.

The business impact is concrete: regulatory exposure when PII, PHI, or payment-adjacent data sits in an open collection; billing abuse when an unrestricted key burns through document reads, bandwidth, or function invocations; integrity loss when write access allows records to be altered or deleted; and extortion risk when an attacker demonstrates a full export before demanding payment.

The uncomfortable part is that conventional tooling is largely blind here. There is nothing to patch, no banner to fingerprint, no server header to correlate against a CVE. If your program is organized around CVE-driven vulnerability scanning, BaaS exposure lives entirely in the gap.

How attacks / risks work

BaaS exposure follows a short, reliable chain.

Step 1 — Discovery. Attackers harvest client-side JavaScript, source maps, and public repositories. Firebase API keys match a stable prefix (AIza...); Supabase anon keys are JWTs whose payload claims the anon role. Project identifiers are enumerable too: Firebase Hosting serves a configuration document at __/firebase/init.json, and project IDs are often guessable from product names. Subdomain enumeration, certificate transparency logs, and DNS records surface web.app, firebaseapp.com, and supabase.co hostnames quickly.

Step 2 — Endpoint mapping. With a project identifier, the data plane maps itself without credentials:

• Firestore REST endpoints under firestore.googleapis.com/v1/projects/<project>/databases/(default)/documents/.
• Realtime Database JSON endpoints, where a ?shallow=true query cheaply enumerates top-level keys.
• Cloud Storage listing endpoints for buckets that permit object listing.
• Supabase's PostgREST surface at /rest/v1/, which advertises its schema through the OpenAPI description it serves by default.

Step 3 — Authorization testing. This is where the real finding lives. The attacker presents the public key and reads the response:

• Does an unauthenticated read of a collection return documents?
• Does a rule such as allow read, write: if request.auth != null fall to any account — including one the attacker self-registers or an anonymous session?
• Does a match path in Firestore rules cover the wrong prefix, leaving sibling collections unguarded?
• Are RLS policies present for SELECT but absent for INSERT, UPDATE, or DELETE — turning a read leak into a write primitive?
• Do views expose underlying tables because they run with the definer's privileges rather than the caller's?
• Do rpc/ functions marked SECURITY DEFINER perform privileged work for anonymous callers?

Step 4 — Abuse. Exfiltration is the obvious outcome, but the quieter variants do more damage: injecting records into an auth-adjacent table to escalate privileges, poisoning application state, harvesting secrets stored inside documents for reuse elsewhere, abusing callable functions as open relays for email or server-side request forgery, and exhausting quotas to cause billing or availability damage.

Two keys deserve special attention. For Firebase, an unrestricted API key (no HTTP referrer or app restriction) can be paired with Identity Toolkit endpoints to mass-create accounts or abuse sign-in flows — making key hygiene a first-class control. For Supabase, a leaked service_role key bypasses RLS entirely and should be treated as a root database credential: the response is rotation, not rule edits.

Detection and visibility

Good visibility into BaaS exposure needs three data sources, and most teams have one.

1. Client-side and source discovery. Continuously fetch and parse JavaScript bundles, source maps, and service worker registrations from every web property you own — including shadow properties found through subdomain and certificate transparency enumeration. Extract candidate keys, project IDs, backend hostnames, and endpoint paths. Static configuration such as Firebase's __/firebase/init.json and Supabase client initialization blocks is high signal. Do the same across public repositories, package registries, and container images, because the same keys leak there.

2. Configuration-state testing. Discovery is a hypothesis, not a finding. Evidence comes from an authorization probe: attempt a bounded read against each discovered collection, table, view, and bucket from both an unauthenticated vantage point and a low-privilege authenticated one, then record the HTTP status, the row or document count returned, and the exact request used. Those two vantage points produce two different findings with different severity; collapsing them loses information.

3. Runtime and platform telemetry. Configuration answers is this exposed? Telemetry answers is it being used? Both belong in a mature program:

• GCP Cloud Audit Logs for Firestore, Realtime Database, and Storage, filtered for unauthenticated principals and unusual read volumes.
• Supabase Postgres logs, API gateway logs, and Edge Function logs, watching for broad select patterns, high row counts, and requests from unfamiliar ASNs.
• Egress and cost anomalies — a spike in document reads, storage downloads, or function invocations is often the first sign a key is being abused at scale.
• Authentication anomalies: bulk signups, anonymous-auth volume, and repeated failed sign-ins against your own project.

The discipline that makes this work is pairing every discovered endpoint with a tested authorization result and a last verified timestamp. Rules change with every deployment, so an exposure finding without continuous revalidation decays into fiction within a sprint.

Reduce risk / best practices

1. Deny by default, then open deliberately. Write Firebase rules and Supabase RLS policies that fail closed. An empty rule set should break your application, not expose it.
2. Make RLS mandatory for every exposed table. If a table must not be reachable through PostgREST, move it out of the exposed schema or revoke grants — do not rely on the absence of a policy.
3. Test rules and policies in CI. Use the Firebase emulator suite and a Postgres test harness to assert, per collection or table, that unauthenticated and low-privilege reads and writes fail.
4. Audit for the any-authenticated-user trap. request.auth != null and auth.role() = 'authenticated' are access controls only if signup is restricted. If anyone can register, they are equivalent to public.
5. Check views and database functions explicitly. Views must run with the caller's privileges, and SECURITY DEFINER functions must validate the caller before doing privileged work.
6. Constrain keys. Restrict Firebase API keys by referrer, app, and API; disable unused Identity Toolkit signup paths; keep service_role and admin credentials strictly server-side.
7. Disable bucket listing. Public object access and public listing are different decisions; most apps need the first and never want the second.
8. Watch the bill. Budget alerts on document reads, storage egress, and function invocations are cheap intrusion detection for key abuse.
9. Validate before you escalate. Not every discovered key is exploitable. Confirm the authorization result with a bounded, non-destructive probe before generating a ticket.

How Trusteed CTEM helps

• Inventory that includes BaaS endpoints. Trusteed CTEM discovers domains, IPs, services, and technologies across external and internal attack surface through passive and active discovery, then keeps them under ongoing scan plans — so platform-hosted properties stop being invisible.
• Dedicated API surface testing. BaaS exposure is fundamentally an API authorization problem, and Trusteed runs a dedicated API surface worker that tests exposed endpoints rather than treating them as ordinary web pages.
• Validation before alarm. Scanner output is a signal, not a verdict. Trusteed's finding validation and SOC gate checks exploitability and business context so analyst queues focus on actionable risk (should_alarm) instead of every discovered key string.
• Exploitability-aware prioritization. Findings are enriched with catalog CVE data and EPSS/KEV context where available, so the dashboard ranks a genuinely open dataset above a hardened project with a cosmetic issue.
• Depth where it counts. A deep DAST worker covers critical web applications sitting in front of your BaaS backends, complementing the API-focused checks.
• Continuous, reportable coverage. Ongoing scan plans plus framework-oriented compliance views and customer reporting turn one-off BaaS audits into a program you can evidence.

See the workflow at app.trusteed.io and the platform background at trusteed.io.

Trusteed CTEM vs point tools

Capability	Typical point tool	Trusteed CTEM
BaaS endpoint discovery	Manual JS review or one-off scripts	Continuous passive and active discovery of domains, services, and technologies feeding a live asset inventory
Authorization testing	Stops at "key found" or a generic template match	API surface worker exercises endpoints, and findings are validated for exploitability before analyst review
Exploitability context	Severity score only	Catalog CVE data with EPSS/KEV context and exploit references where available
Noise control	Every scanner hit becomes a ticket	Finding validation and the SOC gate surface actionable risk (should_alarm) for the queue
Application depth	Generic DAST with shallow coverage	Dedicated API surface testing plus a deep DAST worker for critical applications
Coverage model	Point-in-time scan	Ongoing scan plans across external and internal surface
Reporting	Raw export	Framework-oriented compliance views and customer reporting

Nuclei, Trivy, and similar tools remain genuinely useful — fast, template-driven, and strong for CI and container checks. The distinction is scope: they produce signals. A CTEM program adds inventory, continuous validation, prioritization, and the operator workflow that turns signals into resolved exposure.

FAQ

Is a Firebase API key in my JavaScript a vulnerability? Not by itself. Firebase API keys are identifiers, not secrets, and Google expects them to be public. The vulnerability appears when a public key meets permissive rules, an unrestricted key configuration, or enabled anonymous signup. Report the combination, not the string.

How do I check whether my Firestore rules are open? Test them. The Firebase emulator suite lets you assert expected allow/deny behavior per collection in CI, and the rules simulator supports ad-hoc checks. For production verification, run a bounded read against the REST endpoint with your public key from an unauthenticated context and confirm you receive a permission error.

What is the fastest way to find Supabase tables without RLS? Query the PostgREST endpoint with the anon key and an explicit column selection. A 200 response containing rows means RLS is not blocking that path. Repeat for views and rpc/ endpoints, and remember that an empty result is not proof of safety — it may simply mean the table is empty.

Can an attacker write to my data, or only read it? Both are possible. RLS policies are per-command, so a table with a SELECT policy and no write policies is only writable if some other policy grants it. Test each command separately; read findings and write findings carry different severity.

How is CTEM different from running a scanner against my BaaS projects? A scanner answers "did any of my templates match?" CTEM answers "what do I own, what is actually exploitable, what changed since the last check, and who is fixing it?" It combines continuous inventory, validation that filters false positives, exploitability context, and a prioritized workflow. Trusteed CTEM implements that loop — see trusteed.io.

Is a DAST scanner enough for BaaS exposure? Usually not. A scanner sees an ordinary HTTPS API and has no way to know that /rest/v1/users should require authentication in your application. BaaS testing depends on discovering the project, learning its schema, and evaluating authorization per object — asset inventory and configuration validation work, not payload fuzzing.

Related resources

• Trusteed CTEM platform — product overview and vulnerability intelligence
• Trusteed CTEM app — attack surface inventory, scanning, and validated findings
• Firebase Security Rules documentation — Firestore, Realtime Database, and Storage rule semantics
• Supabase Row Level Security guide — policy design for the exposed schema
• OWASP API Security Top 10 — Broken Object Level Authorization and Broken Function Level Authorization
• OWASP ASVS — access control verification requirements
• CISA Known Exploited Vulnerabilities catalog — exploitation context for prioritization
• NIST Cybersecurity Framework 2.0 — identify, protect, detect, and respond outcomes