Your Deploy Just Went Live. Now Run This Security Checklist.

Your SSL certificate is the first thing every visitor's browser checks. If it's expired, every user sees a security warning and most will leave immediately. If it's about to expire (within 30 days), you're one missed renewal away from a complete site outage.

What to verify: Certificate is valid. Expiry is more than 30 days away. Auto-renewal is configured (Let's Encrypt on most platforms handles this). HTTPS is enforced — HTTP requests redirect to HTTPS, not serve content.

Common failure mode: You set up Let's Encrypt manually six months ago. The cron job for renewal failed silently. You find out when a customer emails you that your site is "not secure."

Security headers are HTTP response headers that tell browsers how to handle your app. They're invisible to users but protect against XSS, clickjacking, MIME sniffing, and protocol downgrade attacks. Missing them is a free vulnerability that requires no exploitation — it's just not protected.

The five headers you need: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options, Referrer-Policy.

In Next.js, add them in next.config.js under the headers() function. In Express, use the helmet middleware — it adds all of these in one line.

This is the most common critical finding in post-deploy scans — and the most embarrassing, because it's entirely preventable. An API key that leaks in a JavaScript bundle or API response is immediately readable to anyone who opens DevTools.

What gets exposed: OpenAI API keys (someone racks up a huge bill). Stripe secret keys (someone processes fraudulent charges). Supabase service role keys (someone reads your entire database). AWS credentials (someone mines crypto in your account).

The rule: any key that says 'secret,' 'private,' or 'service_role' stays on the server. Use NEXT_PUBLIC_ only for genuinely public configuration (publishable Stripe keys, analytics IDs, feature flags).

CORS (Cross-Origin Resource Sharing) controls which websites can make requests to your API from a browser. If you set Access-Control-Allow-Origin: * (the developer's shortcut when CORS errors appear), you've told every website in the world they can make requests to your API.

For most APIs, this means: malicious sites can read your users' data on their behalf (using their session cookies). For AI APIs, it also means: attackers can run LLM inference at your expense from any website.

The correct setting for production: Access-Control-Allow-Origin: https://yourapp.com — your specific domain only.

Within minutes of a new domain appearing in DNS, automated scanners probe it for common sensitive paths. These include: /.env, /.git/HEAD, /api/debug, /admin, /phpinfo.php, Spring Boot actuators like /actuator/health, /actuator/env, and dozens more.

If any of these return 200 (OK), they're exposing data. A /.env response leaks your entire environment. A /.git/HEAD response confirms your stack. A /api/debug endpoint might expose request logs, user data, or internal state.

The fix isn't just 403 Forbidden — return 404. A 403 tells an attacker the endpoint exists and they just can't access it. A 404 is a dead end.

Adding a Content-Security-Policy header is step one. But a misconfigured CSP provides false security. Common mistakes: using unsafe-inline without a nonce (defeats the purpose of CSP), using wildcard source directives (script-src *), or setting a CSP that's so restrictive it breaks your app and gets removed.

A well-configured CSP prevents: XSS attacks from executing injected scripts, data exfiltration to unauthorized domains, clickjacking and UI redressing.

Start with report-only mode if you're not sure: Content-Security-Policy-Report-Only lets you test your policy without breaking anything. Tighten it over time.

Rate limiting is what stands between your production infrastructure and a script that hammers your API 10,000 times per minute. Without it: your database gets overloaded, your LLM bill spikes, and a determined attacker can brute-force auth endpoints.

For AI apps specifically, rate limiting is critical — every unprotected request to an LLM endpoint costs you money. For auth endpoints (login, signup, forgot-password), rate limiting prevents credential stuffing attacks.

Minimum viable rate limiting: 100 requests/minute per IP on API endpoints. Stricter for auth endpoints (10/minute). Stricter still for LLM endpoints (10/minute per user).