You shipped with an AI coding tool, people are using the app, and nobody has checked it. You do not need to check everything today. You need to check the things that would let a stranger read your users’ data, take over an account, or run up your bills.
The free checklist ranks all 77 checks. Sixteen are critical. This guide runs the ones you can do in an afternoon, from the outside first, because those are the ones anyone on the internet can find.
Before you start
- Your live app URL, and a test account that is not an admin.
- Your repository open in your AI coding tool.
- A note to record each result as pass, fail or unknown.
Only test an app you own or have written permission to test.
The order
- Can the public key read your tables? Most AI-built apps ship a public client key in the browser. Ask your coding tool to find it, then try to read a user table with it while signed out. Any row returned is a critical finding.
- Is a server secret in the bundle? Open your live site, view the loaded JavaScript, and search for secret-looking strings: a live payment key, a service role key, a cloud access key. A hit is a live leak; rotate it today.
- Can one user read another user’s records? Sign in as your test user, open one of your records, and change the ID in the URL or request to someone else’s. If it loads, that is a critical finding.
- Is every protected route checked on the server? A redirect in the browser is not a check. Ask your coding tool to list every API route and say which ones verify the session on the server before touching data.
- Is your upload storage listable? Request the root of your storage bucket. A listing of files must be denied.
- Are secrets in your history? Turn on secret scanning in your repository host. It checks past commits, which a local search never sees.
Ask your coding tool to check
For the checks that need the code, paste this with the repository open.
Act as a security reviewer. Do not change any code. For each check below, answer PASS, FAIL or UNKNOWN, cite the file and line that proves it, and explain in one sentence. 1. Every route that accepts a record ID filters by the signed-in user on the server. 2. Every protected API handler verifies the session on the server before reading or writing data. 3. Admin routes check the role on the server, not a flag the browser sends. 4. No API key, token or connection string is hardcoded in source. 5. Row level security is enabled with per-user policies on every table holding user data.
What to do with a fail
Criticals have a 7 day deadline. Fix them in the order you found them, using the fix prompts in the checklist, then run the same check again. A fix is only done when the check passes.