The Repo Review checklist
The seven areas every paid Repo Review walks, whether or not an automated tool pointed at them. Free to use on your own app.
Most security problems in AI-built apps are not exotic. They are the same handful of things, missed because the tool that wrote the code was never asked about them. Walk this list against your own repository. When you want it done for you, with the file and line for every finding, order a review.
1. Authorization
- Row-level security: for every table, do the policies match what the app's queries actually do? A table with RLS off and a client-side key is readable by anyone with the anon key.
- IDOR: every route or server action that takes an id. Does it check that the caller owns the row, or does it trust the id?
- Role checks on admin paths. Is "admin" decided on the server, or by a flag the client sends?
- Server actions and API routes callable without a session. List them; each one needs a reason to be public.
2. Secrets
- Anything in the client bundle: keys prefixed
NEXT_PUBLIC_,VITE_,REACT_APP_ship to the browser by design. - Committed history: a key deleted in the latest commit is still in
git log. Rotate it. - Service-role or admin keys imported anywhere that is not clearly server-only.
3. Payments
- Amount or price taken from the client request instead of looked up on the server.
- Webhook signature verification: the handler must verify the provider's signature before trusting the event body.
- Idempotency: replaying the same webhook or checkout must not fulfil twice.
4. AI endpoints
- Unauthenticated or unmetered calls to a language model: anyone can run up the bill.
- Prompt injection that reaches tools: if model output can trigger a database write, an email, or a shell, what stops a user's input from steering it?
5. Rate limiting and abuse
- Signup, login, password reset: throttled per IP and per account?
- Expensive endpoints (search, export, AI calls): a limit that a script would hit.
6. Data exposure
- Over-broad selects:
select('*')on a table that has a password hash, an email, or an internal note in it. - Public storage buckets and signed URLs that never expire.
- Verbose error responses that return stack traces, SQL, or internal ids to the client.
7. Dependencies
- Known CVEs in what you actually ship, and whether the vulnerable code path is reachable from your app. An audit tool's list is the start, not the finding.
How the paid review uses this
An automated pass (Semgrep, gitleaks, npm audit or pip-audit, and
built-in checks) produces candidates. Then every candidate and every area above is read in the
code and judged reachable or not. Only what is real goes in the report, each with the file and
line, the impact, a fix snippet, and an effort estimate. See the
sample report for what that looks like.
About Repo Review Order a review, from $79