Open database exposure scanner before your app launch

An open database exposure scanner should verify that your production app cannot read, list, write, or infer sensitive records without valid authorization. For AI-built apps, the fastest answer is: scan the public site, bundled JavaScript, API routes, and backend-as-a-service rules before launch, then manually confirm every high-risk finding. Use an AISHIPSAFE security scan to catch obvious exposure before users do.

Open database exposure scanner checks

A useful scan does not just ask whether a database port is open. Modern apps often expose data through client SDKs, permissive rules, anonymous API routes, or leaked tokens. The scanner must test how the app behaves from the outside, as an unauthenticated user would.

The most common checks are:

Unauthenticated reads from tables, collections, buckets, or REST endpoints.
Public writes that allow record creation, profile edits, or object uploads.
List operations that reveal IDs, emails, orders, messages, or filenames.
Anonymous role access that is broader than the product needs.
Service role key exposure in JavaScript, source maps, logs, or public files.
Public data store paths that return structured records without a session.

These checks matter because many AI-generated apps wire the frontend directly to Firebase, Supabase, or a hosted database API. That pattern can be safe, but only when authorization is enforced at the data layer. If the frontend hides a button but the backend accepts the request, the database is still exposed.

A scanner should also separate noise from real risk. A public marketing CMS entry is not the same as a customer table. A health endpoint is not the same as a query endpoint returning user metadata. Good results show the URL, method, observed response, affected data type, and the identity used during the test.

Where exposure usually starts?

Most exposure starts at the boundary between fast product work and missing authorization. AI coding tools often generate working flows first, then add security later. That can leave temporary rules, broad policies, and debug endpoints in place when the app reaches production.

Firebase and Supabase deserve special attention because they are designed to be called from the browser. A Firebase app can safely expose client config, but unsafe rules can still allow a database leak. Start with a Firebase misconfiguration check if your app uses Firestore, Realtime Database, Storage, or callable functions.

Supabase has a similar pattern. The anon key is expected in the browser, but row level security must define what that anonymous role can do. If RLS is missing or a policy is too broad, unauthenticated database access can happen through normal client APIs. Use a Supabase security scan before launch if your app stores user, tenant, billing, or private workflow data.

Secrets create another route to exposure. A database URL, service key, admin token, or cloud credential in a public bundle can bypass every carefully written UI check. Public files such as .env, source maps, static JSON, and build logs should be scanned. A public .env exposure check is a practical first pass.

Look for these failure patterns during review:

A demo policy remains active after launch hardening.
A client route calls an admin endpoint without server-side session checks.
A storage bucket allows public listing, not only public object reads.
A search endpoint returns records across tenants.
A debug route accepts arbitrary table or collection names.

These issues rarely look dramatic in the code. They usually look like convenience: allow all during prototyping, return full objects for speed, or trust the frontend to hide private fields. Attackers do not need source access to test those assumptions.

Run a focused prelaunch review

A prelaunch review should be narrow and evidence-driven. Do not try to audit every line of code on the final day. Focus on the public attack surface and the exact paths that can touch customer data.

Use this checklist:

Map data entry points: frontend SDKs, API routes, server actions, webhooks, storage buckets, and admin panels.
Test signed-out access: fetch pages, API routes, storage paths, and SDK calls without cookies or tokens.
Test low-privilege access: create a normal user and attempt cross-tenant reads and writes.
Review rule files: Firebase rules, Supabase policies, object storage rules, and edge function guards.
Search public artifacts: JavaScript bundles, source maps, static files, and deployment previews.
Record evidence: save request, response, status code, role, and affected data class.
Retest fixes: confirm the same request now fails safely.

For Supabase-backed apps, one quick database-side check is whether public tables have RLS enabled. This does not prove policies are correct, but it catches a high-severity baseline mistake.

sql

select schemaname, tablename, rowsecurity
from pg_tables
where schemaname = 'public'
  and tablename not like 'pg_%'
order by rowsecurity asc, tablename asc;

-- rowsecurity = false needs review before launch

For deeper validation, combine automated crawling with authenticated flow tests. A scanner can find exposed endpoints, but it may need a test user to confirm tenant isolation. A deep scan is most useful when your app has login, billing, dashboards, files, or private AI outputs.

A good test set includes at least three identities: signed out, user A, and user B. User A should never read or modify user B records. If the app supports teams, add a second organization. Cross-tenant access bugs are often missed because the happy path only tests one account.

Fix findings without delays

The right fix depends on the exposure path, but the principle is consistent: enforce authorization where the data is returned or changed. Hiding elements in React, disabling buttons, or checking a query parameter is not enough.

For read exposure, start with deny by default. Then add narrow rules for records owned by the current user, records in the current organization, or intentionally public content. Return only the fields needed by the screen. Avoid returning full user objects when the UI only needs a display name.

For write exposure, require a verified session and validate ownership server-side. Do not let the client choose privileged fields such as role, plan, tenant_id, is_admin, credit_balance, or owner_id. If a user can set those fields directly, the database is accepting trust from the wrong place.

For storage exposure, separate public assets from private files. Public avatars and marketing images can live in a public bucket. Contracts, exports, invoices, transcripts, and uploaded documents should use signed URLs, scoped paths, and server-side permission checks. Also block public listing unless listing is an intentional product feature.

For leaked credentials, rotate exposed keys before redeploying. Removing the key from the bundle is not enough if anyone could have copied it. Replace the credential, check access logs where available, and update deployment secrets. Then scan again for old and new values.

Before shipping, classify each finding:

Critical: private data readable or writable without authorization.
High: cross-account access, broad anonymous policies, or exposed admin credentials.
Medium: excessive metadata, public listing, weak object access, or verbose errors.
Low: non-sensitive public data with confusing configuration.

Only critical and high findings should block launch automatically, but medium issues still deserve owners and dates. The goal is not perfect security. The goal is no obvious exposed database path in production.

Final launch decision

Do not treat the scan as a checkbox. Treat it as a launch gate for data access. If signed-out users cannot read or write private records, low-privilege users cannot cross tenants, and secrets are not public, you have removed the highest-risk exposed database paths. Ship only after retest confirms the fixes.

Faq

What should this scanner test first?

Start with unauthenticated access to database-backed endpoints, client SDK calls, and storage URLs. Then test a normal user against another user's records. The first goal is to prove private data cannot be read, listed, modified, or inferred without the right session and ownership checks.

Is a public frontend database key always dangerous?

Not always. Some client keys are designed to be public, including Firebase config and Supabase anon keys. The danger is what that key can access. If rules or policies allow broad reads, writes, or listing, a normal public key can still expose sensitive records.

How often should i scan for exposure?

Scan before launch, after major auth or data model changes, and after adding new integrations. Also scan when deployment settings change, because previews, static files, and environment handling can expose secrets. For active SaaS apps, scheduled checks reduce the chance of silent regressions.

If you are preparing to launch, run AISHIPSAFE before announcing the app. It gives you a focused second pass on exposed data paths, leaked secrets, and risky public surfaces.