The pre-launch security checklist for founders shipping with AI

You built something. AI wrote half of it, you wired up the rest, and tomorrow it goes live. The code works, the demo lands, and the only thing standing between you and your first real users is a deploy button. This is exactly the moment most security holes get shipped, because "it works" and "it's safe to expose to the internet" are not the same checklist.

The good news is that the most common ways early apps get broken are boring and well-documented. You don't need a security team. You need an hour, this list, and the discipline to actually run through it instead of telling yourself you'll do it after launch. Here's what to check the day before you ship.

Get secrets and API keys out of your code

AI coding tools love to paste a key inline "just to get it working." Then it gets committed, and now your Stripe secret lives in your git history forever.

• Grep your repo for anything that looks like a key: sk_, AKIA, long base64 blobs, password =. Check old commits too, not just the current files.
• Confirm .env and any credentials files are in .gitignore, and that they were never committed before you added them.

The common mistake is thinking that deleting a key from the latest commit removes it. It doesn't. If a secret ever touched a public repo, rotate it now and assume it's compromised. That's the one action that matters here: rotate anything that leaked, don't just delete it.

Check who can access what

Every app with logins has objects that belong to specific users: invoices, projects, uploads, profiles. The question is whether user A can reach user B's stuff by changing a number in the URL.

• Pick an endpoint like /api/orders/123 and try /api/orders/124 from a different account. If you get someone else's data, you have an IDOR.
• Look at every route that takes an ID and confirm the server checks ownership, not just that the user is logged in.

The common mistake is trusting the frontend. Hiding a button doesn't protect the endpoint behind it. Authorization has to live on the server, on every request. This class of bug, broken access control, sits at the top of the OWASP Top 10, explained for a reason: it's everywhere and it's easy to miss.

Treat all input as hostile

Anything a user can type, a user can weaponize. Form fields, URL parameters, headers, file names, JSON bodies. If it comes from outside, it doesn't get trusted.

• For databases, use parameterized queries or your ORM's safe methods. Never build SQL by concatenating strings, no matter how innocent the value looks.
• For anything rendered back into a page, make sure it's escaped. User-supplied content dropped raw into HTML is how you get stored XSS.

The common mistake is sanitizing in one place and forgetting another, so the comment field is safe but the display name isn't. The fix is to escape on output, everywhere, by default, and let your framework do it rather than hand-rolling it.

Lock down authentication

Auth is where small mistakes turn into account takeovers. The basics are well understood, which means there's no excuse for skipping them.

• Rate-limit login, password reset, and any code-entry endpoint. Without a limit, an attacker can brute-force at machine speed.
• Set sane session behavior: secure, httpOnly cookies, sessions that actually expire, and invalidation on logout and password change. Offer MFA for anything that touches money or admin powers.

The common mistake is rolling your own auth because it seemed simple. It isn't. Use a vetted library or provider, and make sure password reset tokens are random, single-use, and short-lived. The action that matters: put a rate limit on every endpoint that accepts a password or a code.

Fix your configuration

Most production incidents in young apps aren't clever exploits. They're a setting someone forgot to flip before going live.

• Turn off debug mode. A stack trace in production hands attackers your file paths, library versions, and sometimes credentials. Serve generic error pages instead.
• Lock CORS to your actual domains, not *. Check that any cloud storage bucket is private by default, and that admin panels aren't reachable without auth.

The common mistake is shipping with the framework's development defaults still on. Those defaults are tuned for your convenience, not for being exposed to strangers. Walk through your production config explicitly and assume nothing is safe until you've confirmed it.

Audit your dependencies

You didn't write most of your code. Your package manager pulled in hundreds of libraries, and any one of them can carry a known vulnerability straight into your app.

• Run npm audit, pip-audit, or your ecosystem's equivalent, and actually read the high-severity results.
• Update what's outdated, and remove packages you imported once and never used. Less surface, fewer problems.

The common mistake is treating the audit warning as background noise and clicking past it. A known CVE in a dependency is a published, searchable invitation. The fix is mundane and effective: patch the high-severity findings before launch, not after the first incident report.

Lock down transport and headers

Everything between your user's browser and your server should be encrypted and locked, and a few HTTP headers do most of that work for free.

• Force HTTPS everywhere and redirect HTTP to it. No login form, no API call, nothing should travel in plaintext.
• Add the headers that matter: HSTS, a Content-Security-Policy, X-Content-Type-Options: nosniff, and a sane referrer policy.

The common mistake is assuming the hosting platform handles all of this. Some of it, maybe. The security headers usually aren't on unless you set them. Run your domain through a free header scanner and fix whatever comes back red. This and the rest of the checklist are covered in more depth in how to pentest your web app before launch.

Run a real scan

You've now done the manual pass, which is genuinely worth doing. But you wrote this code, and you're the worst person to find your own blind spots. The point of a scan is to have something adversarial go looking for what you can't see.

• A scan probes the things you skimmed: the endpoint you forgot to protect, the parameter you didn't think was user-controlled, the misconfiguration three layers deep.
• It gives you findings ranked by severity, with reproducible evidence, so you fix what's actually dangerous first instead of guessing.

Kalit Pentest runs about twelve specialist agents in parallel, moving from recon to exploitation to a report in minutes. The scan is authorized-only and non-destructive, every finding carries a CVSS severity, the steps to reproduce it, and how to fix it, and you can export the results as SARIF, PDF, or HTML. It's the difference between a few minutes before launch and a multi-week firm engagement that runs €15–20k.

Here's the whole list, in the order to run it the day before launch:

1. Get every secret and API key out of code and git history, and rotate anything that leaked.
2. Confirm the server checks ownership on every request, not just that someone's logged in.
3. Use parameterized queries and escape all output to shut down injection and XSS.
4. Rate-limit auth endpoints, fix session and cookie settings, and offer MFA.
5. Turn off debug mode, lock CORS, and confirm storage and admin routes aren't public.
6. Audit dependencies and patch the high-severity findings.
7. Force HTTPS and set the security headers your platform won't set for you.
8. Run an automated scan to catch what the manual pass missed.

Manual review catches the bugs you think to look for. A scan catches the ones you don't, and at this stage those are the ones that bite. Do both, then ship.