hammering.aihow it works
free · read-only · finds open databases in AI-built apps

You built it with AI.
It's probably leaking data right now.

1 in 5 apps built with Lovable, Bolt, or v0 expose real user data to anyone with the URL. Scan yours free — see exactly what's open, and get the exact fix.

https://

read-only · we fetch only what your visitors' browsers already download

Scans apps built with

LovableBolt.newv0CursorReplitBase44SupabaseFirebaseVercelNetlify

The difference

Every scanner tells you your database is open. We hand you the exact fix — and prove it's closed.

You didn't vibe-code because you know SQL — so we don't stop at the finding. We generate the exact policy and re-run the attack to show it worked.

hammering demo-app.lovable.app···
reading the JS a visitor downloads…
CRITSupabase table "profiles" readable by anyone
CRITOpenAI key sk-proj-… exposed in /assets/chat.js
HIGHNo Row Level Security on 3 tables
MEDMissing Content-Security-Policy header
-- hammering.ai · fix for "profiles"
ALTER TABLE public."profiles"
  ENABLE ROW LEVEL SECURITY;

CREATE POLICY "own_rows" ON public."profiles"
  FOR ALL USING (auth.uid() = user_id);

live demo · find → fix → verified closed, on loop

This isn't hypothetical

Security researchers keep scanning AI-built apps and finding the same thing: open databases, in the wild, leaking real data.

What we hammer

Five read-only checks plus one honest score, tuned for the way AI-built apps actually break.

Leaked secrets

Finds server keys baked into your JS — service_role, sk_live, OpenAI, AWS. Public-by-design keys (anon, publishable) are correctly ignored, not flagged.

Open database

The #1 vibe-coded killer: a Supabase table with no Row Level Security, readable by anyone with your anon key.

unlocks with domain ownership

Security headers

Checks CSP, HSTS, clickjacking protection and more — the browser-level defenses default hosting usually skips.

Exposed files

Probes for a downloadable .env, .git, source maps and SQL dumps — matched by real content, not just a 200 status.

Error handling

Sends malformed input and watches for a leaked stack trace or a 500 — signs of missing validation.

A real score

One honest 0–100 survival score. A leaked key or open table pushes you toward 0 — it isn't averaged away.

Who it's for

You built it with AI

You shipped a real app on Lovable or Bolt without knowing what RLS is. Find out — in plain English — what's exposed and exactly how to close it.

You have real users now

It works, people are paying, and a leak now means churn, refunds, and your name in a breach headline. Watch it continuously so a new change can't re-open a hole.

You ship for clients

You hand AI-built apps to clients and need to prove they're not leaking before you invoice. Get a report that shows the holes found — and closed.

Before you scan

What happens to your app

We're a security tool — so we hold ourselves to the bar we measure.

1

Read-only, from the outside

We only fetch what any visitor's browser already downloads. The deep database check reads table names and row counts — never the values, and never writes anything.

2

We never hold your keys

No credentials, no accounts, no database on our side. The fix is SQL you review and run yourself, in your own Supabase — we never touch your production system.

3

Nothing is stored

Your report lives inside a signed link, not on our servers. Close the tab and there's nothing left with us to leak.

4

Ownership-gated deep scan

The database probe only runs on a domain you've proven you own (DNS, meta tag, or a file). We won't enumerate a stranger's data.

Find out before your users do.

A free, read-only scan takes about 20 seconds. If your database is open, you'll know — and you'll have the exact fix.

Scan my app →

free · read-only · no signup