Sample report
An example report for a deliberately-vulnerable demo app — every issue in plain language, with the exact fix to paste back into your builder.
https://my-saas.lovable.app
Issues found — fix before publishing.
A point-in-time check for the specific issues below — not a comprehensive audit or a guarantee of security.
Anyone can read your users' private data
Your database has no lock on it. Right now, anyone — not just your logged-in users — can read every row in your `users` and `orders` tables, with no login and no password. This is the single most common and most serious mistake in vibe-coded apps.
We pulled 47 rows from users · no login, no account
Redacted for your safety — the real values were fully readable. This data is never stored.
Paste this into your builder to fix it
Turn on Row Level Security for all my tables in Supabase. For each table (users, orders), enable RLS and add a policy so that a user can only read and edit their own rows (where the row's user_id equals auth.uid()). Do not allow public/anonymous read access to any table containing personal data.
Prefer to do it by hand?
- Open your Supabase dashboard → Authentication is fine, go to Table Editor.
- For each table, click the table → … menu → Edit table → toggle on 'Enable Row Level Security'.
- Then Policies → New policy → 'Enable read for users based on user_id'.
Your Stripe secret key is visible to everyone
Your private Stripe key is sitting in the code that every visitor's browser downloads. With it, someone could issue refunds, read your payment data, or run charges. Secret keys must never be in the browser — only on a server.
Paste this into your builder to fix it
Remove the hardcoded Stripe secret key (sk_live_…) from the frontend code. Move all Stripe calls that use the secret key into a secure server-side function (an edge function / serverless route), and read the key from an environment variable there. The browser should only ever use the publishable key (pk_…).
Prefer to do it by hand?
- Rotate the key immediately in your Stripe dashboard (Developers → API keys → roll the secret key).
- Delete the old key from your app's code.
- Store the new secret key as a server-side environment variable / secret, not in the frontend.
Anyone can open your users' uploaded files
Your file storage is open. Anyone on the internet can list and download everything users have uploaded — profile photos, and anything else stored in these buckets — without logging in.
Exposed right now · no login required
Paste this into your builder to fix it
In Supabase Storage, make my 'avatars' and 'documents' buckets private (turn off the public flag) and add access policies so that a file can only be read by the user who owns it. Keep only genuinely public assets in a separate public bucket.
Prefer to do it by hand?
- Open Supabase → Storage → each bucket → Settings → turn off 'Public bucket'.
- Add a storage policy so users can only read their own files.
Missing a basic protection against injected scripts
Your app doesn't send a Content-Security-Policy. It's a safety net that makes it much harder for an attacker to run malicious scripts on your site. Not urgent, but worth adding before you grow.
Paste this into your builder to fix it
Add a Content-Security-Policy response header to my app that only allows scripts and styles from my own domain and the services I actually use. Start in report-only mode so it doesn't break anything, then enforce it.
Prefer to do it by hand?
- If your host supports custom headers, add a Content-Security-Policy header.
- Start with Content-Security-Policy-Report-Only to test safely.
What Assay kept from this scan
- 1 exposed secret seen — 0 stored. We record where a key leaked, never the key itself.
- A few rows read, 0 stored. To prove your database is readable we pulled a small sample, masked every value before it reached this page, and wrote none of it down.
- We kept the 4 findings above and nothing else — no page content, no source code, no secrets.
Read-only, ownership-gated, SSRF-guarded. We scan only what a browser can already see.
In a real report, every finding has a re-check.
Paste the fix into your builder, then press it. Assay runs that one check against your live app again and tells you whether the issue is actually gone — usually a single request, fast enough to use as a loop while you work. It can’t run here, because this report describes a demo app that was never deployed.
You can’t confirm your own fix any more than you can clear your own app. “I applied the change” and “the hole is closed” are different claims.