SaaS Launch Security Checklist: 15 Things to Check Before Going Live

New domains get probed by automated scanners within hours of DNS registration. Your app doesn't need to be famous to be targeted — it just needs to be on the internet. The good news: the most critical pre-launch security checks take less time than writing your Product Hunt description.

This checklist covers the 15 most important items. Some take 30 seconds to verify. A few require code changes. All of them matter before your first user signs up.

SSL & Transport Security

✅ 1. SSL Certificate Is Valid and Not Expiring Soon

Check your certificate's expiry date right now. Most hosting platforms (Vercel, Netlify, Railway) handle Let's Encrypt auto-renewal — but managed certificates and custom domain setups can and do expire. A common scenario: you set up your custom domain, the certificate was issued, and it expires 90 days later. If auto-renewal failed silently, users see a browser security warning on your launch day.

How to check: Click the lock icon in Chrome → Certificate → Expiry. Or use openssl s_client -connect yourapp.com:443 2>/dev/null | openssl x509 -noout -dates. Or let Scantient check it automatically with a free scan.

✅ 2. HTTP Redirects to HTTPS (No Mixed Content)

Test that http://yourapp.com redirects to https://yourapp.com. Then open DevTools → Console and check for mixed content warnings (HTTP resources loaded on an HTTPS page). Mixed content triggers browser warnings and can undermine the security of your HTTPS connection.

✅ 3. HSTS Header Set

The Strict-Transport-Security header tells browsers to always use HTTPS for your domain, even if a user types http://. Without it, a user on a shared network can be downgraded to HTTP on their first visit (before the redirect).

Minimum: Strict-Transport-Security: max-age=31536000; includeSubDomains

Security Headers

✅ 4. Content-Security-Policy (CSP) Configured

CSP is the primary defense against XSS attacks. It tells the browser which scripts, styles, images, and other resources are allowed to load on your page. A permissive CSP is better than none; a strict CSP provides meaningful protection. At minimum, set a CSP that disallows unsafe-eval and restricts script sources.

In Next.js, configure CSP in next.config.js headers. In Express, use helmet().

✅ 5. X-Frame-Options Set

Without X-Frame-Options: DENY or SAMEORIGIN, your app can be embedded in an iframe on any site. Attackers use this for clickjacking — overlaying invisible buttons on your app to trick users into clicking things they didn't intend to. One line of config, zero cost, eliminates the entire attack surface.

✅ 6. X-Content-Type-Options: nosniff

This header prevents browsers from MIME-sniffing responses away from the declared Content-Type. Without it, a browser might interpret a user-uploaded file as executable JavaScript. Set it to nosniff and forget about it.

✅ 7. Referrer-Policy Set

Controls how much URL information is sent in the Referer header when users navigate away from your site. Without a policy, full URLs (including query parameters, which may contain tokens or sensitive data) can be leaked to external sites. Set strict-origin-when-cross-origin as a safe default.

API & Authentication Security

✅ 8. No API Keys Exposed in Client-Side Code

This is the #1 mistake in startup apps built with AI coding assistants. Search your entire codebase (including generated code) for any NEXT_PUBLIC_ variables that contain secret values, and for any API keys or tokens hardcoded in JavaScript files that ship to the browser.

Check your deployed JavaScript bundle: open DevTools → Sources → search for known key prefixes (sk- for OpenAI, pk_ for Stripe, etc.).

✅ 9. All Auth-Protected Routes Verify Auth Server-Side

For every API route that returns user-specific or sensitive data, verify that the auth check happens server-side — not just in the frontend component. Test this manually with curl: call your API routes without any auth headers or cookies. If they return data, your auth is frontend-only.

✅ 10. CORS Locked to Specific Origins

Test your CORS policy by sending a request with an Origin header from a domain that shouldn't have access:

curl -H "Origin: https://evil.com" -I https://yourapp.com/api/users

If the response contains Access-Control-Allow-Origin: https://evil.com or Access-Control-Allow-Origin: *, your CORS policy is too permissive.

✅ 11. Rate Limiting on Auth Endpoints

Your login, password reset, and OTP endpoints are targets for brute-force and credential stuffing attacks. Test that repeated failed requests result in rate limiting or lockout. Implement exponential backoff after failed attempts. At Vercel scale, you can handle this at the edge with Vercel's WAF or an inline middleware.

Data & Information Exposure

✅ 12. No Sensitive Endpoints Exposed

Test for common dangerous paths that attackers probe automatically:

• /.env — environment variables
• /.git/HEAD — git repository access
• /api/admin, /admin — admin panels
• /phpinfo.php — PHP configuration
• /actuator/health, /actuator/env — Spring Boot actuators

Each should return 404 (not 403 — 403 confirms the path exists). Scantient checks all of these automatically in a free scan.

✅ 13. Error Messages Don't Leak Internal Details

Trigger an error in your API (bad request, missing param, invalid ID) and examine the response. It should return a user-friendly error message and a status code — not a stack trace, database error message, ORM query, or internal file path.

In Next.js, make sure you're not returning caught errors directly: return NextResponse.json({ error: 'Internal server error' }, { status: 500 }) — not return NextResponse.json(error).

Dependencies & Supply Chain

✅ 14. No Known Critical CVEs in Dependencies

Run npm audit (or your package manager's equivalent) and check for critical or high-severity vulnerabilities. You don't need to fix every low-severity finding before launch — but critical CVEs in dependencies you actively use should be addressed.

For automated ongoing scanning, Snyk and Dependabot are both free for small projects and run in GitHub Actions.

✅ 15. No Secrets Committed to Git

Run a secrets scan against your entire git history before your first public launch. Secrets committed and then deleted are still in git history — visible to anyone who clones your repo if it's ever made public, and visible to everyone right now if the repo is already public.

Quick scan: npx trufflehog git file://. --only-verified. If it finds anything, rotate the exposed credentials immediately — then remove them from git history with git filter-repo.

The 60-Second Shortcut

Items 1–3 (SSL), 4–7 (headers), 8 (API key exposure), 10 (CORS), and 12 (exposed endpoints) can all be checked in a single 60-second external scan. Paste your URL into Scantient's free scanner and get a security score covering all of them — before you announce your launch.

Items 9, 11, 13, 14, and 15 require a few minutes of manual testing or your CI pipeline. Do them in parallel while the scan runs.

Quick Reference: Pre-Launch Security Checklist

SSL & Transport

• ✅ 1. SSL certificate valid, not expiring within 30 days
• ✅ 2. HTTP redirects to HTTPS, no mixed content
• ✅ 3. HSTS header configured

Security Headers

• ✅ 4. Content-Security-Policy set
• ✅ 5. X-Frame-Options: DENY or SAMEORIGIN
• ✅ 6. X-Content-Type-Options: nosniff
• ✅ 7. Referrer-Policy configured

API & Auth

• ✅ 8. No API keys in client-side code or NEXT_PUBLIC_ variables
• ✅ 9. All protected routes verify auth server-side
• ✅ 10. CORS locked to specific origin allowlist
• ✅ 11. Rate limiting on auth endpoints

Data Exposure

• ✅ 12. No sensitive paths exposed (/.env, /.git, /admin, actuators)
• ✅ 13. Error messages don't leak stack traces or internal details

Dependencies & Secrets

• ✅ 14. No critical CVEs in production dependencies (npm audit)
• ✅ 15. No secrets in git history (TruffleHog scan)

For more checklists tailored to your stage, see our security checklist overview, our post-deploy security checklist, and the indie dev security checklist.