Skip to content
Chapter 06 · 11 min

Hardening before launch

The previous chapters were the five holes. This one ties them into a checklist you run before you let strangers in, adds the remaining basics an AI tool skips (headers, dependencies, error handling) and answers the real question: when is this safe enough to ship, and when do you bring in help?

“The pre-flight checklist exists because memory fails and the cost of forgetting is the whole plane.”

The pre-launch checklist

Before launch, walk this once, deliberately, the way an attacker would. It's the whole course as a list. If you do nothing else, do this:

  • Data access: every table has Row-Level Security with a real policy; a second user and an anonymous request are both blocked (ch.2).
  • Secrets: no secret keys in the client bundle or git; anything that leaked is rotated; keys live server-side (ch.3).
  • Authorization: every id-bearing endpoint checks ownership on the server; you've tried changing an id and been refused (ch.4).
  • Exposed surface: endpoints inventoried, dead routes deleted, CORS locked to your origins, rate limits on auth and costly routes (ch.5).
  • Webhooks: every inbound webhook verifies its signature and rejects an unsigned call (ch.5).

Set the headers the tool skipped

Security headers are a few lines of configuration that turn on browser-level protections, and AI tools almost never add them because nothing breaks without them. They're cheap insurance against whole classes of attack:

  • Content-Security-Policy: restricts what scripts and resources may load, blunting cross-site scripting. The highest-value and the fiddliest to get right.
  • Strict-Transport-Security (HSTS): forces HTTPS so a user can't be downgraded to an interceptable connection.
  • X-Content-Type-Options: nosniff and X-Frame-Options / frame-ancestors stop content-type tricks and clickjacking via embedding.
  • And the baseline beneath all of them: serve everything over HTTPS, with no mixed content.

A reasonable Content-Security-Policy is the one to actually invest in: it's the difference between a stray script being inert and it running with your users' sessions. Start in report-only mode so you can see what it would block before you enforce it.

Your dependencies are part of your attack surface

An AI tool pulls in packages freely, and every dependency is code you're trusting and shipping. The fast-moving AI/JS ecosystem is a fertile field for known vulnerabilities, typosquats, and abandoned libraries. The hygiene is standard and worth automating: audit what you depend on, pin versions, and patch known issues before they're exploited.

  • Run a vulnerability scan (npm audit, or a tool like Dependabot/Snyk) and fix the criticals before launch.
  • Pin versions so a dependency can't change under you, and review what a new package actually is before adding it.
  • Keep a habit of updating; an unmaintained dependency is a slow-motion vulnerability.

Errors and logs: don't narrate the internals

AI-built apps love to return the raw error to the screen: stack traces, SQL messages, file paths. Each is a free map of your internals for an attacker. Show users a generic message; log the detail server-side where only you can read it. And while you're there, make sure you're logging enough to notice an attack: failed logins, authorization denials, rate-limit trips.

When to bring in help

This course makes the common, serious holes findable by the person who built the app, and for many projects, running the checklist honestly is enough to launch responsibly. But the more you're handling (real payments, health or financial data, anyone else's sensitive information) the higher the cost of the hole you didn't think to look for, and the more it's worth having someone review the app whose full-time job is finding those.

That's the work SDEN does: hardening and reviewing AI-built applications against exactly these failure modes, with the SOC 2 / CCPA / PIPEDA framing North American customers expect. If you've built something with AI and you're about to put real users' data behind it, a security review before launch is far cheaper than the incident after. Pair this with the AI Security course for the model-specific threats, and you have the full picture.

In one line each

  • Run the pre-launch checklist deliberately: data access, secrets, authorization, exposed surface, and webhooks, the whole course as a list.
  • Add the basics AI skips: security headers (especially a real CSP), HTTPS/HSTS, dependency scanning, and non-leaky error handling.
  • Re-run the checklist after changes: regenerating code with AI silently drops guards, so security is a loop, not a milestone.
  • Automated scanners catch mechanical holes; broken authorization needs human judgement, so for sensitive data, get a review before launch.

Where to go next

Hardening before launch · AI courses · SDEN