The fetched pages did not state a time limit on test mode rules, so no expiry figure is recorded.
Firebase's client SDKs talk to Firestore, Realtime Database and Storage directly from the browser or app, so Security Rules are the whole access layer. When you create a database you choose Locked mode (deny all) or Test mode (allow anyone).
Firebase's docs state that API keys only identify the project, that server SDKs bypass rules, and that Firebase alerts you when rules allow open access. Testing a Firebase app is mostly reading the rules and trying them from a second account, with App Check and the Rules Playground as the vendor's own tools.
Each row is taken from the vendor's documentation on the date shown. Defaults change; the date is the claim.
| Area | Default | Source |
|---|---|---|
| Default rules for new Firestore / RTDB (locked vs test mode) | When creating a database you choose Locked mode (default rules deny access to all users) or Test mode (allow anyone access). For Cloud Storage, locked mode restricts access to authenticated users. | docs · verified 2026-09-21 |
| Test mode | Firestore test mode is good for getting started with client libraries but allows anyone to read and overwrite your data; production mode denies all reads and writes from mobile and web clients. | docs · verified 2026-09-21 |
| API key exposure model | Firebase API keys only identify the project; authorization is handled by IAM, Security Rules and App Check, so keys restricted to Firebase services do not need to be treated as secrets. | docs · verified 2026-09-21 |
| Server SDK scope | Server client libraries bypass all Firestore Security Rules and authenticate with Application Default Credentials; rule updates take up to a minute to affect new queries and up to 10 minutes to propagate fully. | docs · verified 2026-09-21 |
| Open rules | Rules that allow read/write to all users let anyone overwrite the database; Firebase sends an alert when data is not properly secured, per the insecure rules page. | docs · verified 2026-09-21 |
Documentation home: firebase.google.com/docs
27 patterns in the catalogue name Firebase; the most severe are listed here across secrets and keys, data access, login and permissions, ai features, deploy and config, mobile. Attribution is descriptive: the default stack makes the pattern reachable, or a public incident names it.
Everyone who can see the repository, now or later, holds working keys to the database, payment account and model provider, and the keys stay in history after the file is deleted.
Anyone with the app's public Firebase config, which sits in its JavaScript, can read, overwrite or delete the entire database and storage bucket without signing in.
Anyone who changes the id in a URL or request can read, edit or delete another customer's record.
Anyone who creates a free account can page through every other customer's records, which is a data breach with a sign-up form as the only step.
A stranger who types /admin or /api/admin into the address bar can see or change everything the owner can.
Anyone who calls the API directly, or edits the page in developer tools, gets the data and actions the screen was hiding.
Anyone who reads the code or guesses a common placeholder can sign in as the administrator.
Anyone can write their own token naming another user, or an admin, and the server will act as that person.
A visitor who edits the signup request, or updates their own profile, can make themselves an admin.
Whoever can influence the model's input can delete tables, email your whole customer list, or trigger any other action the app has wired up.
Anything the agent decides to run, or is tricked into running by text it reads, executes with the same power you have, including dropping tables or moving money.
Anyone who downloads the app from the store can unzip it and read the key, then run up your bill or read your database as an administrator.
Anyone who views the page source can take the key and run up charges, send messages or pull data on your account until the key is revoked.
Keys, session tokens and database connection strings end up in log files and in HTTP responses that anyone can trigger, which hands out credentials and a map of the system's internals.
Anyone who has or guesses a file link can download customer uploads such as ID scans, contracts or invoices, with no login.
Lovable reported that from 3 February to 20 April 2026 a backend regression let any logged-in Lovable user read the chat history and source code of public projects; a fix shipped within two hours.
Apr 2026 · Lovable · all sources
One education app built on Lovable had 16 vulnerabilities, 6 critical; a database function denied callers whose role was 'authenticated', so anonymous callers passed and 18,697 user records were readable without login.
Feb 2026 · Taimur Khan · all sources
A scan of 1,645 Lovable-built apps found 170 (about 10.3%) with database endpoints readable without login because Supabase row-level security policies were missing or too broad; recorded as CVE-2025-48757, CVSS 9.3.
May 2025 · Matt Palmer (Replit, Inc.) · all sources
On the Base44 app builder, undocumented registration and one-time-password endpoints accepted a non-secret app_id, so anyone could create a verified account on a private app; Wix fixed it within 24 hours.
Jul 2025 · Wiz Research · all sources
Each entry links to its primary source in the evidence list. What to do about it is the self-check below.
Stated from the vendor's documentation. The limits are the vendor's scope statements, not judgements.
Rules Playground (simulator)
Simulates reads or writes at a path as unauthenticated, anonymous or a specific user, for Realtime Database, Firestore and Cloud Storage.
Where it stops: The docs direct you to the Firebase Emulator for full validation and automated unit tests.
vendor docs · verified 2026-09-21
App Check
Attests that requests come from your authentic app or an untampered device, for Firestore, Realtime Database, Cloud Storage, callable Cloud Functions and other services, with monitoring and enforcement configured separately.
Where it stops: The docs state App Check prevents some, but not all, abuse vectors directed at your backends.
vendor docs · verified 2026-09-21
Security Rules
Per-path rules for Firestore, Realtime Database and Cloud Storage, editable in the console or CLI.
Where it stops: Rules apply to client SDK traffic only; server SDKs bypass them.
vendor docs · verified 2026-09-21
Insecure rules alerts
Firebase alerts you when your data is not properly secured and documents common rule mistakes to fix.
Where it stops: The page does not specify the alert channel or timing.
vendor docs · verified 2026-09-21
The critical patterns first. Each uses the dashboard and your browser.
.env, .env.local, .env.production, serviceAccountKey.json or firebase-adminsdk files.sk_live, sk-, service_role, BEGIN PRIVATE KEY and password=.git log --all -p -S sk_live -- . | head. Any output means a live key has been committed at some point.allow read, write: if true, ".read": true, ".write": true, or a rule that checks only request.auth != null on private data.if true rule on a live project, or a banner warning about your rules.A bad result is account A's record appearing for account B, or an edit or delete going through.
Firebase pre-launch checklist
27 checks, in the order we run them. Usable without buying anything.
Self-check tool
Answer questions about your setup and get the patterns that apply, ordered by severity. Runs in your browser; nothing is sent.
For founders about to let real users in.
$490
For anyone who wants the three riskiest areas checked fast.
$290
All packages and prices. Every report includes a re-check after your fixes.
A rule that reads allow read, write: if true, or a Realtime Database rule with .read and .write set to true, lets anyone with the project id read and overwrite data. Open the Rules tab, look for those lines, and use the Rules Playground with an unauthenticated request to confirm what is reachable.
We read every rule set, try reads and writes as an anonymous client and as two signed-in users, check whether App Check is enforced, and look for keys and config in the bundle. Findings name the rule path to change.
Firebase's docs say the API key identifies the project and does not grant access by itself; rules, IAM and App Check do. Restricting the key in Google Cloud is still good practice, but the rules are what you test.