The 5-minute pre-deploy security checklist (for anyone shipping fast)
You're about to push to production. You have five minutes. Maybe you're a solo founder deploying after midnight, or a vibe-coding team shipping a client site. Either way, here's the checklist that catches the majority of real-world breaks — the stuff automated attackers find within minutes of your deploy, before your users do.
#The five-minute pass
#1. Run a free passive scan (30 seconds)
This is the whole board in one shot. A passive scan checks for SQL injection, XSS, open redirects, missing security headers, exposed files, outdated software, and more — no account, no credit card, results in seconds on vergate.dev/free-scan.
Ship rule: no new critical or high findings, or don't ship. That's it.
#2. Security headers (20 seconds)
Three headers do most of the work:
Content-Security-Policy— the one that stops most XSS deadStrict-Transport-Security(HSTS) — forces HTTPS for everythingX-Content-Type-Options: nosniff— kills MIME-sniffing attacks
Quick check: curl -sI https://your-site.com | grep -iE "content-security|strict-transport|x-content-type".
Any of the three missing is a deploy blocker for anything public.
#3. Exposed files (30 seconds)
This is the one people forget, and it's the highest-value line on this list:
/.git/config— if this loads, your entire source is readable/.env,/config.yml,/*.sql,/backup.zip— credential gold mines/wp-admin/,/admin/,/debug— control panels with no lock
Automated scanners probe these within minutes of your domain going live.
A passive scan checks them for you, or do it by hand: curl -sI https://your-site.com/.git/config
and look for 200.
#4. Secrets (20 seconds)
- No API keys in client-side code (they're visible to everyone)
- No secrets in public repos — run a scan on your repo before you push
- Rotate anything that leaked. Always. Not "soon."
#5. Dependencies (30 seconds)
npm audit/pip-audit/ your ecosystem's equivalent — fix anything critical- Outdated components with known CVEs are the #1 entry point for automated attacks. A scan cross-references your detected stack against known vulnerabilities so you don't have to track CVE feeds yourself.
#6. Redirects and TLS (30 seconds)
http://should redirect tohttps://permanently (301)wwwand apex should point at one canonical host — pick one, redirect the other- Check no redirect loops:
curl -sIL https://your-site.comshould terminate in one or two hops, all HTTPS
#7. Cookies (20 seconds)
Session cookies should be HttpOnly, Secure, and SameSite. If you see a
session cookie without all three, fix it before shipping anything that
authenticates users.
#After the five minutes
- Every production deploy, not just big ones. Regressions sneak in through "small" changes — a dependency bump, a config tweak, a new analytics tag.
- Automate it. The same checks that took five minutes by hand can run in CI: Vergate's API lets you scan on every merge and gate on a score floor, so the habit becomes automatic.
- Once a month, do the deeper pass. Run an active scan on staging, run an accessibility and performance audit, review your monitoring alerts. The five-minute pass is the floor, not the ceiling.
#The one line to remember
Scan before you ship, check headers and exposed files, and never skip
secrets. Most breaches aren't sophisticated — they're a .env file with a
200 status and a deployment that didn't spend five minutes looking. Don't be
the deployment that didn't spend five minutes.
Frequently asked questions
Is five minutes actually enough?
For the automated pass, yes — a free passive scan of a typical site completes in seconds, and each checklist item below is a single command or a single scan module. It won't replace a penetration test, but it catches the top of the attacker checklist, which is where most real-world damage happens.
Should this run in CI instead of by hand?
Ideally both. The checklist works by hand for a quick deploy; the same checks can run as an API call in your pipeline (a scan on every merge, gated on a score floor) so the five-minute habit becomes automatic.
What's the number one thing people forget?
Exposed files and directories: .env backups, .git directories, leftover config files. They're silent, they're findable by automated scanners within minutes of your deploy, and they leak credentials and source. Check them every time — it's the highest-value line on this list.
Do I need to do this on every single deploy?
Every production deploy, yes. The whole point is that regressions sneak in through 'small' changes — a dependency update, a config change, a new third-party script. The automated part costs seconds; the surprise part costs a weekend.