A Security Checklist for Apps You Did Not Write Line by Line
Written By
SprintX Team
AI & Product Engineering
July 30, 2026
7 min read
A working checklist for founders who shipped fast with an AI builder and now need to know the app is safe — every item with a way to verify it yourself.
You prompted your way to a working product. It looks good, people are asking for logins, and somewhere between the demo and the first paying customer you realized you cannot personally vouch for a single line of it.
That is a normal position to be in — roughly 46% of new code shipped in 2026 is AI-generated, and most of the people shipping it are not reading it line by line either. What you need is not a course in application security. You need a finite list of things to verify, phrased so you can check each one yourself.
This is that list. Work top to bottom; the order is deliberate, because the early items are the ones that leak money and data while you sleep.
How to use this
Every item has a pass criterion, not a vibe. "It seems fine" is not a pass. If you cannot demonstrate the pass condition, mark it failed and move on — you are triaging, not fixing, on the first run through.
Budget two to three hours for the whole list on a small app. Most founders find between four and nine failures. That is expected, and almost none of them require a rewrite.
1. Secrets
Check: build your app for production and search the output files for key-shaped strings — "sk_", "service_role", "AKIA", "AIza", and any prefix your providers use. Pass: zero results.
If anything turns up, that key is public. Rotate it today, then move the call server-side. Keys with a client-safe prefix are fine by design; everything else is not. The full failure mode, including what to do in the hour after you find one, is in API keys exposed in the frontend.
Check: search your git history, not just current files, for committed .env files and credentials. Pass: clean history, or every found secret rotated. Deleting a file does not remove it from earlier commits — see finding every secret an AI left in your repo for the tooling.
Check: every environment variable that holds a secret is set in your hosting provider, not in a committed file. Pass: the repo contains an example file with empty values and nothing else.
2. The data layer
This is where the quiet disasters live, and it is the item most often skipped because the app behaves perfectly while you test it as yourself.
Check: create two accounts. Log in as B. Take a record ID belonging to A — from a URL, a network request, anywhere — and request it as B. Pass: you get denied. Not an empty screen because the UI hid it. An actual authorization failure from the server.
Check: list every table in your database and confirm each one has access rules enabled, with a policy that references the current user. Pass: no table is readable by any authenticated user by default. A policy that evaluates to "true" counts as a failure. Common variants are catalogued in Supabase RLS mistakes in AI-built apps.
Check: file storage. Try opening an uploaded file's URL in a private window while logged out. Pass: denied, or a signed URL that expires. Public buckets are how customer documents end up indexed.
Check: you have a backup and you have restored from it once. Pass: you personally watched a restore succeed. Untested backups are folklore.
3. Auth and sessions
Check: signup enforces email verification, or you have accepted the consequences of not verifying. Pass: a deliberate decision, documented.
Check: password reset tokens are single-use and expire. Pass: using a reset link twice fails.
Check: admin routes are enforced on the server. Pass: calling an admin API endpoint with a normal user's token returns 403. If the only thing protecting admin is that the menu item is hidden, you have no admin protection at all.
Check: sessions expire and logout invalidates the token server-side. Pass: a token captured before logout stops working after it.
4. Input and abuse limits
Check: every API route validates its request body against a schema. Pass: sending an unexpected field, an oversized string, or a wrong type returns a clean 400 rather than a 500 or a silent write.
Check: database constraints exist — unique indexes, foreign keys, NOT NULL. Pass: you cannot create two accounts with the same email by racing two requests. Most duplicate-record complaints come straight from this gap.
Check: rate limits on login, signup, password reset, and anything that calls a paid model. Pass: a loop of 200 requests gets throttled. Without this, one script can drain a month of API budget overnight — the mechanics are in rate limiting an AI app.
5. What the outside world can see
| Item | Fast check | Pass |
|---|---|---|
| Error responses | Trigger a failure in production | Generic message, no stack trace or SQL |
| CORS | Inspect the allowed origin header | Your domains only, not a wildcard |
| Security headers | Run any online header scanner | HSTS, X-Content-Type-Options, a CSP present |
| Debug endpoints | Search routes for anything named test, debug, seed, or admin-tools | None reachable in production |
| Source maps | Check the deployed asset folder | Not published, or access-restricted |
| Dependencies | Run your package manager's audit command | No known criticals, every package exists on the registry |
6. Before you call it done
Two habits matter more than any single fix. First, write down who has access to what — the hosting account, the database, the AI provider, the domain registrar — and remove anyone who no longer needs it. Founders routinely leave a contractor with production database access for a year.
Second, put a change gate in front of the app. Even a one-person team benefits from a branch, a staging deploy, and a five-minute smoke test before production. It is the cheapest way to stop the AI from silently undoing a fix you already made, which is a real and frequent failure mode. The broader launch sequence, security and everything else, lives in our production readiness checklist.
When to stop and bring in help
Stop self-serving this list if any of the following is true: you found a secret that was live in a public repo for more than a day, you can read another user's data and cannot work out why, you handle health or payment data, or your first enterprise customer just sent a security questionnaire. Those are all situations where the cost of guessing exceeds the cost of an hour of expert time.
Frequently asked questions
How long should this take on a small app? Two to three hours to run the checks, and typically one to three days of work to fix what you find. The data-layer items usually take the longest because you have to decide the rules before anyone can implement them.
Can I skip this if I have no users yet? The secrets and data-access items, no — those are exposed the moment the app is deployed, users or not. Bots find new domains within hours. The rest can wait until you have real traffic.
Is a paid scanner enough on its own? It covers secrets and vulnerable dependencies well. It will not tell you that user B can read user A's invoices, because that code looks perfectly normal. The two-account test above catches more real risk than any scanner we run.
If you have worked the list and the failures are stacking up faster than you can fix them, that is a scoping problem, not a competence problem. SprintX hardens AI-built apps in fixed-scope engagements and hands back a codebase you can defend — tell us what you found.
