Securing a Firebase Studio app: a review checklist

Firebase's documentation says the App Prototyping agent builds web apps with Next.js. It can provision a Firebase project and a Gemini API key for AI features, add Cloud Firestore and Firebase Authentication when you ask, and publish to Firebase App Hosting. When you ask it to add Firestore, the documentation says it writes and deploys Firestore database rules for you. Open your workspace and confirm which of these your project actually has.

That gives the app two kinds of code. Browser code uses the Firebase client SDK and a public config, and whatever it can do is limited only by Security Rules. Server code, such as Next.js route handlers, server actions and AI flows, holds secrets like the Gemini key and must check the caller itself. Rules the agent wrote for you are still rules you have to read.

The same documentation warns that Gemini can generate output that seems plausible but is factually incorrect, and tells you to validate all output and not to use untested generated code in production.

Firebase's documentation on insecure rules names the patterns that expose data, including rules that allow all reads and writes and rules that only check that a user is signed in. Read your rules for those first. Then make the request a stranger would make, against your own project, with no credentials. A permission error is the pass result. A list of documents means the collection is public.

export PROJECT_ID="your-project-id"

curl -s "https://firestore.googleapis.com/v1/projects/$PROJECT_ID/databases/(default)/documents/YOUR_COLLECTION?pageSize=5"

The Firebase web config, including its API key, is meant to be public. Firebase's documentation says those keys identify the project and that authorisation comes from Security Rules, App Check and IAM. The Gemini API key is different: it is a credential that spends your quota, and it belongs only in server code. Next.js inlines any variable that starts with NEXT_PUBLIC_ into the browser bundle, so that prefix must never appear on a secret.

For App Hosting, the documentation describes an env list in apphosting.yaml where each variable has either a plain value or a reference to a secret in Cloud Secret Manager, created with the firebase apphosting:secrets:set command. It also lets you limit a variable to build time or run time. The example shows the intended split. Because apphosting.yaml is normally committed, a plain value there is as public as your repository.

env:
  - variable: NEXT_PUBLIC_FIREBASE_PROJECT_ID
    value: your-project-id
  - variable: GEMINI_API_KEY
    secret: geminiApiKey
    availability:
      - RUNTIME

firebase apphosting:secrets:set geminiApiKey

grep -rn "NEXT_PUBLIC_" .env* apphosting.yaml
git log --all -p -S"GEMINI_API_KEY" | head -50

The Next.js documentation says a server action is reachable by a direct POST request, not only through your interface, and that you should verify authentication and authorisation inside each one. Route handlers deserve the same treatment as public API endpoints. In a Firebase project, that usually means verifying the user's ID token on the server with the Admin SDK before doing any work. Remember that the Admin SDK bypasses Security Rules, so server code that uses it must do its own ownership checks.

An AI feature is also a cost surface. If a stranger can call the route that talks to Gemini, they can spend your quota. Require a signed-in user, limit how often one user can call it, and set a budget alert on the Google Cloud project.

• Assuming rules are safe because the agent wrote and deployed them. Read them.
• Accepting a rule that only checks the user is signed in. Any account can then read everything.
• Giving the Gemini key a NEXT_PUBLIC_ name so a client component can use it.
• Writing a secret as a plain value in apphosting.yaml and committing it.
• Leaving the AI endpoint open to anonymous calls with no limit.
• Testing with the account that owns the data, so cross-user reads are never tried.
• Ignoring the sunset notice until the workspace is gone, then rebuilding config from memory.

Re-read the rules and repeat the logged-out request after every change the agent makes to data access. Repeat the whole list after migrating the project. Pass condition: logged-out requests are denied, the second user cannot read the first user's documents, no secret carries a public prefix or sits in a committed file, and the AI route refuses strangers.