Public database exposure check before launch safely

A public database exposure check confirms that your production data stores are not reachable, readable, or writable by unauthorized users. Before launch, verify network access, database rules, API permissions, exposed admin panels, and leaked connection details. The goal is simple: no unauthenticated path should allow data discovery, data export, privilege escalation, or destructive writes.

Run a public database exposure check

Start by defining what must never be public. For most AI-built apps, the riskiest findings are not advanced exploits. They are simple deployment mistakes, copied example settings, and service keys placed where browsers can see them.

Your first pass should confirm:

No public database ports on production hosts or managed database endpoints
anonymous reads disabled unless the data is intentionally public
client-side service keys absent from JavaScript, HTML, and source maps
weak security rules removed from Firebase, Supabase, or custom APIs
admin consoles blocked from the internet or protected by strong authentication
default credentials removed from dashboards, database users, and tools

An exposed database can be obvious, such as PostgreSQL listening on 5432 from the internet. It can also be indirect, such as an API route that accepts any record ID and returns another user's data. Treat both as launch blockers.

Use a crawler or scanner to look from outside the app, not only from the code editor. A developer machine may hide firewall, DNS, CDN, and hosting behavior. External validation shows what an attacker can actually reach.

If you want a focused companion read, compare this process with an exposed database scanner workflow. For broader misconfiguration coverage, review open database exposure patterns before publishing.

Map every database access path

A useful review covers every route between the public internet and stored data. That includes direct database listeners, backend APIs, serverless functions, storage buckets, GraphQL endpoints, admin dashboards, analytics exports, and generated preview deployments.

Check the provider dashboard first. Managed services often show allowed networks, public access switches, read replicas, API keys, and anonymous permissions in one place. Do not rely on the app framework to protect a database that is directly reachable.

Then inspect DNS records and hosting configuration. AI-generated apps often create preview domains, old staging URLs, and temporary API subdomains. These can keep pointing to live services after the main domain looks clean.

Next, review compiled JavaScript. Public bundles should contain only publishable keys. A key named PUBLIC or NEXT_PUBLIC is not automatically safe. It is safe only if the provider designed it for browser exposure and the backend rules still restrict data access.

Here is a small external reachability check for owned domains. It does not authenticate or attempt exploitation. It only flags common database ports that are reachable and need review.

bash

#!/usr/bin/env bash
HOSTS=(api.example.com app.example.com)
PORTS=(5432 3306 27017 6379 9200)

for host in ${HOSTS[@]}; do
  for port in ${PORTS[@]}; do
    if timeout 2 bash -c 'cat < /dev/null > /dev/tcp/'$host'/'$port; then
      echo 'REVIEW: '$host':'$port' is reachable'
    else
      echo 'ok: '$host':'$port' is not reachable'
    fi
  done
done

Run checks only against systems you own or are authorized to test. If a port is reachable, it does not always mean data is exposed. It does mean the service needs authentication, network restrictions, logging, and a clear reason to be public.

A good manual review also follows application behavior. Create two test users. Sign in as user A, capture a normal request, then try user B identifiers. If user A can fetch user B records, the database may be protected at the network layer but exposed through broken authorization.

For apps using direct client SDKs, treat row permissions as production code. Supabase RLS, Firebase rules, and storage policies should be reviewed with real test accounts, not only by reading intended logic.

Fix the common exposure patterns

Most findings fall into a few repeatable categories. Fix them in order of blast radius. Start with anything that allows unauthenticated reads or writes, then reduce public reachability, then rotate keys that may have leaked.

Use this launch checklist:

deny by default for database, storage, and API access rules.
Restrict database networking to trusted hosts, VPCs, or provider integrations.
Remove direct public access unless a specific service requires it.
Replace browser-exposed secrets with server-side calls.
Apply least privilege to every database role and service account.
Enable audit logs for reads, writes, permission changes, and failed login attempts.
Rotate any key found in bundles, logs, screenshots, tickets, or old commits.
Retest with anonymous users, normal users, and admin users.

The most dangerous pattern is a powerful key shipped to the browser. Once a service role key, database URL, or admin token is public, assume it was copied. Removing it from the frontend is not enough. You need rotated secrets, invalidated sessions where relevant, and a review of recent access logs.

Another common pattern is permissive test rules left in production. Examples include allow read, write if true, broad wildcard collection access, or RLS policies that check whether a user is signed in but not whether they own the row.

For storage-backed apps, remember that files are data too. Public avatars may be fine. Invoices, exports, private uploads, transcripts, and generated reports are not. Check bucket policies and signed URL expiration carefully.

When the app uses a backend API, fix authorization close to the data access layer. Do not rely only on hidden buttons or disabled UI states. Attackers call endpoints directly, replay requests, and change IDs. Server-side ownership checks must happen before every sensitive query.

If you are already scanning for exposed keys, connect this work with a security scan that reviews public attack surface and secret exposure together. Database mistakes and leaked keys often appear in the same release.

Verify the release gate

Verification should be repeatable, not a one-time guess. A release gate is a short set of checks that must pass before production traffic increases, a launch announcement goes out, or a new integration is connected.

At minimum, verify from a clean external environment. Do not test only from inside your VPN, hosting console, or local network. Use read-only probes where possible, and avoid destructive payloads against production data.

A practical release gate includes:

External port review for known database services
Anonymous request testing against public APIs
Two-user authorization testing for record ownership
Review of browser bundles for connection strings and privileged keys
Provider rule review for Firebase, Supabase, storage, and search services
Log review after testing for unexpected reads, writes, or permission errors

Classify any unauthenticated data access as a release blocker. A cosmetic issue can wait. A path that exposes customer records, internal prompts, invoices, API tokens, or private files cannot.

Also scan generated previews. Many teams protect the main production domain while preview URLs keep old code and old environment variables alive. If previews connect to production data, they need the same controls as production or separate low-risk test data.

For deeper review of complex apps, use a deep scan to expand beyond simple reachability into more complete attack surface coverage. If your stack includes serverless functions, auth callbacks, webhooks, and storage policies, a broader scan is usually worth the extra time.

You should also document the final state. Record which domains were checked, which providers were reviewed, which keys were rotated, and who approved the release. This does not need to be formal bureaucracy. A short checklist in the release ticket is enough for most small teams.

Before the final deploy, repeat the scan after environment variables, DNS, and database rules are changed. Security fixes can create new behavior, especially when hosting platforms rebuild bundles or redeploy serverless routes.

A safe launch does not require a massive audit. It requires proving that public users cannot reach private data through ports, APIs, rules, leaked keys, or forgotten previews. Make that proof part of every production release.

Faq

Can i check for exposure without touching real data?

Yes. Use external reachability tests, anonymous requests, test accounts, and read-only queries where possible. Avoid destructive writes in production. For authorization checks, create synthetic records for two test users and confirm each user can access only their own data.

Is a public database port always a breach?

No. Some managed systems expose an endpoint but still require strong authentication and network rules. However, an internet-reachable database increases risk and should be justified. Review firewall rules, allowed IPs, TLS settings, users, permissions, and recent connection logs.

What should i do if a key was exposed?

Rotate the key immediately, remove it from public bundles, and redeploy. Then review logs for unusual access during the exposure window. If the key allowed database reads or writes, check affected records and tighten permissions before issuing a replacement credential.

AISHIPSAFE helps AI-built app teams catch risky exposure before users and attackers do. Run a focused scan before launch, then recheck after every meaningful production change.