Get featured

Before you ship: lock the database, back it up, and log what happens

Guide · checked against the docs on

An app can work fine on your screen while its database is open to anyone. Firebase's docs put it plainly: "You might think you're the only person using your app, but if you've deployed it, it's available on the internet." (source)

This guide is a checklist to run before launch. It covers three jobs: lock the database, make sure you can get your data back, and log what happens without leaking secrets. It's quoted from Supabase, Firebase, MongoDB, PostgreSQL and OWASP docs, checked Oct 2026.

Not affiliated with or endorsed by Supabase, Google, MongoDB, the PostgreSQL Global Development Group or OWASP. Check their current docs before relying on these details.

For keeping API keys out of your code, see how to keep secrets safe with AI coding tools. This guide doesn't repeat it.

Part 1: Lock the database

Check 1: Supabase: turn on Row Level Security for every table

Supabase gives your frontend a public key. That's by design. Supabase's docs explain: "The publishable key is taped to the front door, and it only opens the lobby. The secret key is the master key, and it stays in your pocket." (source)

The lock is Row Level Security (RLS). Without it, the public key opens much more than the lobby: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it. Enable RLS on every table in an exposed schema." Here, "anon" means "an unauthenticated request (the user is not signed in)". (source)

Policies alone aren't enough on some projects. Supabase says: "On projects that still grant anon and authenticated by default, revoke those grants. Adding policies doesn't remove them." And: "A table protected only by policies still hands anon an insert path if you never revoke the grant." (source)

Check 2: Keep the secret key off the browser

The secret key (formerly service_role, checked Oct 2026) is different: "It bypasses Row Level Security, so it must never leave your control". (source)

The key names are changing: "Supabase is deprecating the anon and service_role keys by the end of 2026. Use the publishable (sb_publishable_xxx) and secret (sb_secret_xxx) keys instead." (source)

Check 3: Never allow 0.0.0.0/0

An IP allowlist decides which addresses can connect. In PostgreSQL's words, "0.0.0.0/0 represents all IPv4 addresses, and ::0/0 represents all IPv6 addresses." (source) So adding it to an allowlist lets everyone in.

Check 4: Self-hosted Postgres: no '*' with trust

Two settings together leave a server with no password at all:

A line like this in pg_hba.conf, on a server listening on *, lets anyone who can reach it log in as any user (we haven't tried it ourselves):

host  all  all  0.0.0.0/0  trust

Check 5: Firebase: remove 'if true' rules

Firebase's insecure-rules page lists this rule as not recommended. Its comment warns that it allows "anyone to overwrite your entire database." (source)

allow read, write: if true;

Firebase says: "If you're not authenticating users and configuring security rules, then anyone who guesses your project ID can steal, modify, or delete the data." (source)

Check 6: Tell your agent not to "fix" it by opening up

When a connection fails, the quick fix is to open things up. Add a rule like this to your agent's instructions (we haven't tried it ourselves):

Never turn off RLS, add 0.0.0.0/0 to an allowlist, use trust auth, or
write 'if true' rules to make something work. Stop and explain the
problem and a safer fix instead.

See AI agent permissions for beginners to make the agent ask before it changes settings.

Part 2: Make sure you can get your data back

Check 7: Know whether you have automatic backups

On Supabase, "We automatically back up all Pro, Team, and Enterprise Plan projects on a daily basis." For free tier projects, Supabase recommends they "regularly export their data using the Supabase CLI db dump command and maintain off-site backups." How long backups are kept depends on your plan (checked Oct 2026). (source)

Daily backups still leave a gap: "Even with daily backups, you could still lose a day's worth of data. With PITR, you can back up to the point of disaster." (source)

Check 8: Restore a backup once

Our advice, not a vendor quote: a backup you've never restored is untested. Restore one into a separate test project or database, and check your data is there before you need it for real.

Part 3: Log what happens, safely

Check 9: Log the events that matter

OWASP says: "Without logging and monitoring, attacks and breaches cannot be detected, and without alerting it is very difficult to respond quickly and effectively during a security incident." One common failure: "Auditable events, such as logins, failed logins, and high-value transactions, are not logged or logged inconsistently (for instance, only logging successful logins, but not failed attempts)." Another: "Logs of applications and APIs are not monitored for suspicious activity." (source)

Check 10: Keep secrets out of the logs

OWASP's list of things not to log includes "Access tokens", "Authentication passwords", "Database connection strings" and "Encryption keys and other primary secrets". It also warns: "Logs may contain personal and other sensitive information, or the data may contain information regarding the application's code and logic." (source)

Next steps

Sources

All checked Oct 15, 2026:

Not affiliated with or endorsed by Supabase, Google, MongoDB, the PostgreSQL Global Development Group or OWASP. Check their current docs before relying on these details.