Pre-Launch Security Checklist: What to Verify Before Going Live

Launch day pressure creates blind spots. Security issues discovered in production cost 10x more to fix than pre-launch findings. This checklist helps product and engineering teams verify the essentials before production traffic arrives — in a single review session.

Why Pre-Launch Security Checks Matter

The most dangerous vulnerabilities are the ones that were there on day one and never found. Common pre-launch failures include:

• Exposed .env files — credentials deployed to production accessible via browser
• Debug mode left on — stack traces visible to attackers, exposing architecture
• Default credentials — admin/admin on CMS installs, unchanged DB passwords
• Missing security headers — XSS, clickjacking, and protocol downgrade exposure from day one
• Open ports from dev — databases and admin panels reachable from the internet

A 30-minute automated scan before launch catches most of these. Run the AI QA Monkey free scanner as your first step.

1. SSL and Transport Security

• SSL certificate is valid, not expired, and issued to the correct domain (including www).
• Auto-renewal is configured and tested — Let's Encrypt renewal cron or hosting panel setting confirmed.
• HTTPS redirect is active — all HTTP requests 301 to HTTPS.
• HSTS header is set with at least max-age=31536000.
• No mixed content warnings — all assets (images, scripts, fonts) load over HTTPS.
• TLS 1.2+ only — TLS 1.0 and 1.1 disabled on the server.

# Verify SSL from command line
openssl s_client -connect yourdomain.com:443 -tls1_2

# Check for mixed content in browser DevTools
# Network tab → filter by "http://"

2. Secrets and Exposed Files

This is the most critical category. A single exposed .env file or git repo gives attackers full database and API access.

• .env file returns 403 or 404 — never 200 with content.
• .git/ directory is not accessible — test yourdomain.com/.git/config.
• No backup files exposed — test .bak, .sql, .tar.gz in webroot.
• No debug endpoints — /phpinfo.php, /info.php, /.well-known/ checked.
• All environment variables set via hosting platform config (not hardcoded).
• Database credentials differ from development environment.

# Quick checks
curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/.env
# Expected: 403 or 404, never 200

curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/.git/config
# Expected: 403 or 404

3. Security Headers

• Content-Security-Policy: defined and tested in report-only mode first.
• Strict-Transport-Security: set with min 1-year max-age.
• X-Content-Type-Options: nosniff — present on all responses.
• X-Frame-Options: SAMEORIGIN — or CSP frame-ancestors.
• Referrer-Policy: set to strict-origin-when-cross-origin or stricter.
• All session cookies have Secure, HttpOnly, SameSite flags.

Verify all headers are live with the free security scanner — it checks all headers in one pass against your production URL.

4. Authentication and Session Controls

• No default credentials on any admin panel (WordPress admin, hosting panel, database).
• Admin accounts have MFA enabled.
• Session timeout is configured (recommend 30 min idle for sensitive applications).
• Login rate limiting is active — max 5-10 attempts before lockout or captcha.
• Password reset links expire within 15-60 minutes.
• Admin URL is not the default path (/wp-admin, /admin).

5. API and CORS Checks

• CORS policy is restricted to known, trusted origins — not *.
• No sensitive data returned in unauthenticated API responses.
• Internal API endpoints are not publicly accessible.
• Rate limiting is configured on authentication, password reset, and data-heavy endpoints.
• API error messages do not expose internal paths, DB errors, or stack traces.

# Test CORS policy
curl -H "Origin: https://evil.com" https://yourdomain.com/api/endpoint -v 2>&1 | grep -i "access-control"
# Expected: No ACAO header, or ACAO for trusted domains only

6. Operational Readiness

• Automated backups configured and restore procedure tested in last 30 days.
• Error monitoring active (Sentry, Rollbar, or equivalent).
• Uptime monitoring configured with alerting to on-call contact.
• Security alerts configured for: login failures, privilege escalation, unusual traffic.
• Incident owner and escalation contacts documented and distributed.
• Rollback plan documented and approver identified.
• Debug mode disabled: APP_DEBUG=false, WP_DEBUG=false.

Launch Gate Checklist

Before approving launch, confirm each item:

# Launch security gate — sign-off required before go-live
[ ] Automated external scan completed — 0 critical findings
[ ] All High findings: fixed or documented risk acceptance with owner
[ ] SSL certificate valid and auto-renew tested
[ ] No exposed .env, .git, backup, or debug files
[ ] Security headers baseline enforced
[ ] No default credentials on any admin panel
[ ] CORS policy restricted to trusted origins
[ ] Backups verified and restore tested
[ ] Monitoring and alerting active
[ ] Rollback plan documented

Sign-off: __________________ Date: __________

7. Database and infrastructure readiness

• Database uses production-specific credentials — not the same as development or staging.
• Database is not accessible from the public internet — port blocked at firewall level.
• Database user has least-privilege access — only SELECT, INSERT, UPDATE, DELETE on required tables.
• All database connection strings use the production hostname, not localhost or staging IP.
• Redis/Memcache instances require authentication and bind to internal IP only.

8. DNS and email authentication

• SPF record published covering all authorized sending services.
• DKIM configured and selector resolving correctly in DNS.
• DMARC record published — at minimum p=none with rua= reporting address to begin monitoring.
• CAA DNS record limits which CAs can issue certificates for the domain.
• No dangling DNS records pointing to decommissioned infrastructure (subdomain takeover risk).

# Verify DNS records are live
dig TXT yourdomain.com | grep "v=spf"
dig TXT _dmarc.yourdomain.com
nslookup -type=CAA yourdomain.com

9. Third-party integrations and supply chain

Third-party scripts loaded on the page are one of the most overlooked pre-launch security risks. Each script executes with full page privileges — the same as your own code.

• Inventory all third-party scripts loaded on the page (analytics, chat, marketing, payment widgets).
• Apply Subresource Integrity (SRI) hashes to externally-hosted scripts where possible: <script src="..." integrity="sha256-..." crossorigin="anonymous">.
• Payment page scripts are inventoried and approved per PCI DSS 4.0 Requirement 6.4.3.
• No third-party scripts load additional scripts from domains you do not control.
• CSP script-src allowlist covers all legitimate script sources and blocks unexpected ones.

10. Dependency and code security

• Run npm audit (Node.js), composer audit (PHP), or pip-audit (Python) — 0 critical/high findings before launch.
• Confirm the production build excludes development dependencies (--production or --no-dev flags).
• Source maps are disabled or access-restricted in production — they expose full application source code to browser DevTools.
• Debug tools, test routes, and seed scripts are removed from production deployments.

Frequently Asked Questions

What are the most common pre-launch security failures?

Exposed .env files with database credentials, debug mode left on, missing security headers, CORS set to *, and default admin credentials. An automated scan catches all of these in minutes.

How long should a pre-launch security review take?

Automated scan: 5 minutes. Reviewing findings and confirming each checklist item: 1-3 hours. Remediating any critical findings: depends on severity, but most pre-launch issues can be fixed in under a day.

Can this replace recurring security checks?

No. Use pre-launch checks as a gate, then keep weekly automated scanning and post-deploy checks in place. Attack surface changes with every deployment.

Do we need this checklist for staging environments?

Yes — staging breaches are underrated. Staging environments often have production data, real API keys, and weaker access controls. Apply the same checklist before promoting staging to production.