---
You built the API. It works on your machine, the frontend talks to it, and you are days from pointing a real domain at it. The question in your head is the honest one: what did I miss that a stranger on the internet will find in the first week?
Here is a checklist you can run yourself. It is ordered roughly by how often each item bites solo founders shipping AI-built apps, and how expensive it is when it does. None of this needs a security team. Most of it you can check today.
1. Secrets and keys
This is the one that costs money and leaks data at the same time. A service-role key, a database URL with a password in it, or a cloud provider secret that made it into your source, your git history, or a committed .env file is the single most common way a small app gets drained.
Two things to check, not one:
- Your current files. Search for anything that looks like a key or a connection string that should be in an environment variable instead.
- Your git history. Deleting a secret from the latest commit does nothing if it is still sitting in an earlier one. A key that was ever committed should be treated as burned and rotated, not just removed.
2. Authentication and authorization are different problems
Authentication asks "who are you." Authorization asks "are you allowed to touch this specific record." AI coding tools are good at the first and quietly skip the second. The classic result is an endpoint that checks you are logged in, then hands you any row you ask for by ID, including rows that belong to other users.
Walk each endpoint that reads or writes user data and ask: if I am logged in as user A and I request user B's ID, what stops me. If the answer is "nothing," that is your first fix.
3. Rate limiting and the surprise bill
A public endpoint with no rate limit is a denial-of-wallet problem waiting to happen. Anything that calls a paid API, sends an email, runs an LLM prompt, or writes to storage can be looped by a script until your bill has four extra digits. This is separate from a classic security bug: nobody steals data, you just wake up owing money.
Put a limit in front of anything that costs you money per call, and a lower one in front of anything unauthenticated.
4. Dependencies and typosquats
Your package.json is an attack surface. Check for known-vulnerable versions, and check the package names themselves. AI assistants sometimes hallucinate a plausible package name that does not exist, and attackers register those names on purpose (this is called slopsquatting). Installing one of those is not a bug in your code, it is running someone else's.
5. Input handling on every public route
Anything a public route accepts is untrusted. The usual suspects: SQL and NoSQL injection where user input reaches a query, and injection into any prompt you send to an LLM. If the AI-built version concatenated user input straight into a query string or a system prompt, that is worth a close read before the route is reachable from the open internet.
6. Deploy and config
The code can be fine while the deploy leaks. Common misses: debug mode left on in production, an admin path with no auth, permissive CORS that lets any origin call your API, missing security headers, and storage buckets or database rules set to public read. Check the running configuration, not just the repo, because those two can disagree.
7. What is actually exposed
Before you flip it public, get a plain list of every route your API exposes and confirm each one is meant to be reachable. Debug routes, seed scripts, and internal admin endpoints have a way of shipping by accident.
A faster way to run this checklist
You can do all of the above by hand, and for a small app that is a fine afternoon. If you would rather have a tool read your source and hand you a ranked list, the free IOnclad browser scanner does a subset of these checks in your browser with no signup and no email wall, at theionproject.com/ionclad/scan/. It runs client-side, so your code stays in your browser.
The full IOnclad desktop app runs 24 scanners and 500+ checks across secrets and git history, dependencies and typosquats, the OWASP web categories, session and auth, an API surface map, GraphQL, and a denial-of-wallet check called CostGuard. It scans your own source and config on your machine and returns one Ship-It verdict, safe to ship or not yet, with the file, line, and a fix for each finding. It maps findings to CWE and ASVS controls so you can see your readiness against them. It does not promise your app is secure, and no tool honestly can. What it produces is evidence for the decision you are about to make anyway.
Run the list above, or run the scanner, or both. The point is the same: look before you point a domain at it.