The Canary Check #003: "allow read, write: if true" is still live

One finding, one fix, before you ship.

Finding: Firebase test-mode rules in production

Firebase's own docs are blunt: allow read, write: if true; should never be used in production, because anyone who knows your project ID can read, change or delete your data. Firebase also warns that request.auth != null on its own is too broad, since every signed-in user gets everything.

Fix: scope to the owner.

match /notes/{id} {
  allow read, delete: if request.auth != null && request.auth.uid == resource.data.author_uid;
  allow create: if request.auth != null && request.auth.uid == request.resource.data.author_uid;
  allow update: if request.auth != null
    && request.auth.uid == resource.data.author_uid
    && request.auth.uid == request.resource.data.author_uid;
}

Check: use the Rules Playground in the Firebase console to simulate a signed-out read and another user's write. Both should be denied. Deploying from the CLI overwrites console edits, so keep rules in git.

Guide: https://prodcanary.com/guides/firebase-rules-allow-read-write-if-true-fix/ Source: https://firebase.google.com/docs/rules/insecure-rules

News

Next.js's authentication guide says to treat Route Handlers and Server Actions like public API endpoints, and that Proxy (middleware) checks are optimistic, not your only line of defence. If your AI added /api/* routes, check that each one verifies the user. (https://nextjs.org/docs/app/guides/authentication)

Tip

Vite ships every VITE_-prefixed variable to the browser. Run grep -r "VITE_" .env* and make sure none of them hold a secret. (https://vite.dev/guide/env-and-mode)

Free scan: https://prodcanary.com/#scan