The 60-second pre-launch security checklist
Read this before you deploy
Launching is exciting and you want it live now. This list is the 60-second pause that saves you a bad week. None of it is exotic — it is the handful of mistakes that automated bots check for on every new site, often within minutes of deploy. Walk it, then ship.
1. No secrets in the frontend
Is any API key, token or password reachable in your client-side code or JavaScript bundle? Keys belong on the server, behind your own endpoint. If one was ever in the frontend, rotate it before launch. This is the single most exploited mistake.
2. No public .env or .git
Request /.env and /.git/config on your own deployment. If either returns real content, you are one request away from handing over your configuration or your entire source history. Keep them out of the web root and block dotfiles at the server.
3. No production source maps
Try a bundle URL with .map appended. If it downloads, you are publishing your readable source. Strip source maps from the deploy or upload them privately to your error tracker.
4. Security headers set
At minimum: a Content-Security-Policy without unsafe-inline, HSTS, X-Content-Type-Options: nosniff, an anti-clickjacking rule, and a sane Referrer-Policy. Frameworks rarely add these — someone has to.
5. Session cookies flagged
Every session or auth cookie should carry HttpOnly, Secure and SameSite. A session cookie without them is a session waiting to be stolen.
6. Strong TLS
Your padlock means encrypted, not strong. Confirm you refuse old protocols (SSL, TLS 1.0/1.1), offer no weak ciphers (RC4, DES, 3DES), and that your certificate is valid, matching and has a complete chain.
7. Dependencies in order
Commit your lockfile, install with the locked versions, and make sure you are not shipping end-of-life frontend libraries or a known-compromised package. The code you did not write is still your responsibility.
The honest part
You cannot fully eyeball some of these — a key buried in a large bundle, the exact ciphers your server accepts, a header that did not deploy the way you expected. That is the one minute this checklist cannot give you on its own. The fast way to actually confirm all seven is to scan the deployment before you announce it.
Confirm before you ship
Run your site through an automated scan as the last pre-launch step, clear anything Critical or High, and ship knowing the doors that get found first are shut. Scan your site now.