Skip to content
SealMyApp

For apps built with Lovable, Bolt, Cursor, Replit, v0

Apps built with AI tools often leave your users' data readable by anyone.Check yours free in 2 minutes.

It's easy to ship an app where strangers can read your database, copy your paid API keys or open your admin page. SealMyApp finds these mistakes, gives you a fix to paste into the tool you built with, and checks it worked.

Free · read-only checks · you'll verify you own the app first. Email is optional: we use it to send your report and, if you don't buy, we may send one follow-up about that report. Every email has an opt-out link.

See an example report from a demo app we own.

Example reportyour-app.example
57

3 issues found

2 high · 1 low

  • HighTable “profiles” is readable without login

    Anonymous read allowed. Columns exposed: id, email, full_name.

    Question for you: is “profiles” meant to be readable by anyone? If not, it needs a Row Level Security policy.

Fix prompts tailored to the builder you use

  • Lovable
  • Bolt
  • Cursor
  • Replit
  • v0

What we check

The common mistakes in AI-built apps that leak your users' data or let someone else run up a bill on your keys.

Your database is open

Strangers can read your users' emails, names and other data straight from your database. (Technically: Supabase tables without Row Level Security, or open Firebase rules.)

Secret keys in your app's code

Paid API keys (Stripe, OpenAI, Anthropic, AWS and others) shipped to every visitor's browser, where anyone can copy them and run up your bill.

Private files anyone can download

Files like .env (your passwords and keys), your code history (.git) or database backups that your host hands out to anyone who asks.

Admin pages without a login

Admin screens and API addresses that answer to anyone, no sign-in needed.

Browser safety settings

Missing security headers that help browsers protect your users. Low risk, quick wins.

No scare tactics

Keys that are meant to be public (the Supabase anon key, Firebase web config) aren't reported as problems. Where data might be public on purpose, we ask you rather than assume.

How it works

  1. Prove it's yours

    Paste a one-line prompt into your builder to add a small file, or add a DNS record. About two minutes. We never scan apps you don't own.

  2. We check it, read-only

    We look at your app from the outside, the way a stranger would. We never sign in, change data or guess passwords.

  3. Fix it, keep it fixed

    Copy-paste fix prompts for your builder, a re-scan to confirm each fix worked, and optional daily checks as you keep shipping.

Pricing

Start free. Pay only if you want the fixes, or ongoing monitoring.

Free scan

See where you stand.

£0

  • Verify you own the app (DNS or file)
  • Security score and issue count by severity
  • Your most serious issue explained in full
Scan my app

Fix Pack

Every issue, and exactly how to fix it.

£29one-off per app

  • Every issue in full, with evidence
  • Copy-paste fix prompts for your builder
  • Supabase SQL policies to review and run
  • Re-scan to confirm each fix worked
Start with a free scan

Watchdog

AI edits can quietly undo fixes. We notice.

£9per month per app

  • Daily re-scan of your app
  • Email alert with a fix prompt if something new or re-opened turns up
  • Optional re-scan on every deploy (webhook)
  • Cancel any time from the billing portal
Start with a free scan

Prices in GBP. Fix Pack and Watchdog are bought from your free report.

Our rules

Owned apps only
No scan runs until you've proven the app is yours. We never scan apps you don't own.
We never keep your users' data
At most one row is read to prove exposure, then discarded. We store findings, not data.
Read-only
We never write, delete or brute-force anything.
Honest findings
No scare tactics: public-by-design keys aren't reported as critical.

Questions

What does the scan check?

Whether your Supabase tables or storage can be read with the public anon key (Row Level Security), whether a Supabase service_role key ships in your frontend, open Firebase rules, secret API keys in your JavaScript bundle (Stripe, OpenAI, Anthropic, AWS and others), publicly reachable files such as .env, .git and source maps, admin or API routes that answer without a login, and basic security headers.

Why not just use a free scanner?

You can, and our scan is free too. The difference is what happens after the scan. SealMyApp is built for fixing: you get a copy-paste fix prompt written for the builder you use (Lovable, Bolt, Cursor, Replit or v0), Supabase SQL where needed, and a re-scan to confirm each fix worked. Watchdog then keeps it fixed by re-checking daily, because a later AI edit can quietly undo a fix. And we never scan apps you don't own, so nobody can use SealMyApp to probe yours.

Why do I have to prove I own the app?

We never scan apps you don't own: checking someone else's app without permission can be illegal, and it would make SealMyApp a tool for attacking other people's apps. Before any scan you add a token we give you to your app: as a meta tag in your home page's <head> (we give you a prompt to paste into your builder), a small file at /sealmyapp-verify.txt, or a DNS TXT record. It takes about two minutes.

What do "Row Level Security" and "anon key" mean?

If your app uses Supabase, your frontend contains a public "anon" key so the app can talk to your database. That's normal. Row Level Security (RLS) is the set of rules that decides which rows that key may read or change. If RLS is off, or a rule says "anyone", then anyone who opens your app can copy the key and read the whole table: emails, names, orders. Our scan tests exactly this, and the Fix Pack gives you the SQL rules to close it.

Will the scan change or break anything?

No. Every check is read-only: we only make GET and HEAD requests, within a strict request budget. We never write, delete, or try to guess passwords.

Do you keep any of my users' data?

No. If we prove a table is readable, we fetch at most one row to confirm it, keep only the table name and its column names, and discard the row immediately. Secrets we find are masked before anything is stored.

Is my Supabase anon key a problem?

Not by itself. The anon key and Firebase web config are designed to be public. The problem is what they can access — which is why we test whether your tables actually answer to them, and we don't flag the key itself as critical.

What's in the Fix Pack?

Every issue from your scan explained in plain English, a copy-paste prompt tailored to the builder you use (Lovable, Bolt, Cursor, Replit, v0 or other), SQL policies for Supabase where relevant, and steps to confirm each fix with a re-scan.

Does a clean scan mean my app is secure?

No. A clean result means none of our automated checks found a problem. It doesn't replace a full security review, and it can't see logic bugs inside your app.

Which builders do you support?

Apps made with Lovable, Bolt, Cursor, Replit and v0 — and in practice any web app with a public URL. Fix prompts are tailored to the tool you pick.

Sealed — a short weekly security note for vibe coders

One common security mistake in AI-built apps, how to fix it in your builder, and one useful tool. No spam; unsubscribe any time.