Pre-Launch Security Checklist

What this template is

This is the checklist to run in the final week before a product, or a major feature, goes live. It is written for founders shipping a first product, and for engineers who own a launch and want to sleep the night after. It assumes the code already works; the question here is whether it is safe to expose to the internet, real users, and real data.

The ordering is deliberate. The first three sections are the ones attackers hit within hours of launch (automated scanners find new domains fast). The later sections are what saves you in week two when something goes wrong anyway. Copy the markdown into your launch ticket and require every box checked, with evidence, before the DNS flips.

1. Secrets (do this first)

• Full history scan is clean: gitleaks detect --source . -v on every repo that ships (step-by-step in the secrets scanning tutorial)
• The deployed frontend bundle is grepped for sk_live, AKIA, service_role, and database URLs; nothing found
• All production secrets were created fresh for production, never copied from staging
• Debug and test credentials, seed users, and default admin passwords are removed or rotated
• Cloud IAM follows least privilege: the app’s runtime role cannot delete buckets or read unrelated services

2. Authentication and access control

• Object-level authorization verified with curl: user A cannot read, update, or delete user B’s resources by ID
• Admin functionality requires an admin role checked server-side, and admin accounts have MFA
• Rate limiting is live on login, signup, and password reset
• Session cookies are httpOnly, Secure, SameSite; sessions die on logout
• Any “temporary” auth bypass added during development is gone; grep for TODO, skip_auth, is_dev

3. Public attack surface

• Every route that should not be public returns 401/403 when hit without credentials; test the API directly, not through the UI
• Staging, preview, and internal tools are not reachable on guessable public subdomains without auth
• TLS is enforced everywhere with HSTS; certificates auto-renew
• Security headers are set: CSP, X-Frame-Options or frame-ancestors, X-Content-Type-Options
• Directory listings, .git folders, .env files, and source maps are not served by the web server

4. Data protection

• Backups run automatically, and one restore has been performed successfully this month, not just configured
• Personal data collected is the minimum needed, and the privacy policy matches what the code actually collects
• Data in transit is TLS; data at rest is encrypted where the platform supports it
• Deleting an account actually deletes or anonymizes the user’s data
• Third parties receiving user data (analytics, error tracking, email) are listed and each strips or masks sensitive fields

5. Dependencies and build

• npm audit / pip-audit shows no critical or high findings on the shipping lockfile (full workflow in the dependency audit tutorial)
• The production build installs from the committed lockfile; builds are reproducible
• Dependency update automation (Renovate or Dependabot) is enabled so day-30 is not worse than day-1

6. Monitoring and the bad day plan

• Error tracking is live in production and alerts a human, not a dead Slack channel
• Uptime monitoring hits the real user flow (login, core action), not just the homepage
• Auth events and admin actions are logged with actor and timestamp
• There is a written rollback procedure and it has been executed once as a drill
• One page documents the incident plan: who rotates keys, who takes the site down if needed, who tells users

How to act on the results

Failures in sections 1 through 3 are launch blockers, full stop. A leaked key, a missing authorization check, or an exposed internal tool will be found by automated scanning within days of your domain becoming interesting, and the cost of shipping unaudited code is always paid at the worst possible moment. Failures in sections 4 through 6 are launch-week fixes: ship if you must, but assign owners and dates before you do, using the triage model from how to prioritize fixes after an audit.

Then put a recurring version of this list on the calendar. Launch hardening decays: keys get shared, dependencies age, an engineer adds a debug route. Rerun sections 1, 3, and 5 monthly.

Want us to run it for you (free)

The week before launch is exactly when a second set of eyes is worth the most and when your team has the least spare attention. Submit your repository and a Webisoft engineer will run this pre-launch lens over it manually, then send you a prioritized report of what to fix before you ship, free: get a free code audit.