Guides · ← All guides
Website Security Checklist for Small Teams (60-second self-check)
Last updated: October 31, 2026 · Reviewed October 2026 · 6 min read
Small teams do not need a security department to cover the fundamentals — they need the short list, in the right order, with a test for each item that takes seconds. This is that list. It is not a generic roundup: every item is one of the checks BreachHunter's scan runs, rewritten so you can run it by hand.
The 12-point checklist
| # | Check | The 30-second test | Good looks like |
|---|---|---|---|
| 1 | Certificate valid, auto-renewing | Click the padlock; check the expiry date | In date by weeks, renewal automated |
| 2 | TLS 1.0 / 1.1 refused | Your TLS config (or the free scan) shows enabled protocols | TLS 1.2+ only |
| 3 | HSTS sent | curl -I https://your-site.com | Strict-Transport-Security present |
| 4 | CSP + framing protection | Same response headers | Content-Security-Policy and X-Frame-Options present |
| 5 | nosniff + Referrer-Policy | Same response headers | X-Content-Type-Options: nosniff, a referrer policy set — what each header stops |
| 6 | Cookies flagged | Inspect a session cookie in dev tools | Secure + HttpOnly + SameSite all set |
| 7 | /.env not reachable | Visit your-site.com/.env | 403 or 404 — anything else is CRITICAL |
| 8 | /.git not reachable | Visit your-site.com/.git/HEAD | 403 or 404 — a ref: line means your source is public |
| 9 | No backups in the web root | Probe /backup.zip, /backup.sql, /db.sql | All 403/404 |
| 10 | Database & remote ports closed | Port-check 3306, 5432, 6379, 27017, 3389, 23 from outside | None answer the public internet |
| 11 | Version banners quiet | Read Server / X-Powered-By in the response | No exact version numbers advertised |
| 12 | Admin panel defended | Find your admin login as a stranger would | Behind MFA, rate limits, or an IP allow-list |
Source: each row maps to a named BreachHunter engine check (TLS module items 1–2 · web-audit items 3–9 · ports module item 10 · recon item 11 · directory discovery item 12), app/pentest.py, read October 31, 2026.
How do you score it?
10–12: the fundamentals are in order — put the checklist on a quarterly rhythm and after big deploys. 6–9: fix the failures this week, headers and banners first (they are configuration, not projects). Under 6: run the free scan now and work its report top-down. And one override that beats the arithmetic: failures on items 7, 8, 9 or 10 are same-day fixes at any score — an exposed .env with eleven passes is still an exposed .env. Our triage guide explains why severity outranks totals: which findings to fix first.
What does this checklist not cover?
Everything inside the application: whether your code can be injected, whether users can see each other's data, whether your password reset flow leaks accounts, whether your dependencies carry known vulnerabilities. The checklist is the perimeter an attacker checks first — deliberately. Passing it means the easy doors are shut, which is exactly the state that makes the deeper work worth paying for. When you are ready for that depth, here is what a full assessment adds.
Run all 12 checks automatically — free scan →
Frequently asked questions
How long does this checklist actually take?
About a minute per item if you run the manual tests one by one — call it ten minutes for the set, the first time. The free BreachHunter scan runs all twelve automatically in about a minute, which is the honest version of the 60-second claim: the checklist is the scan's checks, rewritten for humans.
What score should worry me?
Any failure on items 7, 8, 9 or 10 — exposed secrets, exposed source, public backups, or open database ports. Those are same-day fixes regardless of your total. A high score with one of those four failed is not a passing grade.
How often should a small team re-run this?
After every deployment that touches the server, and quarterly otherwise. Misconfigurations are usually introduced by a change, not by time passing — the checklist catches drift, and drift tracking (Pro) watches for it continuously.
Does passing this checklist mean my site is secure?
No. It means the fundamentals an attacker checks first are in order — the exposures responsible for the most common small-site breaches. It does not test business logic, user permissions, or your code for injection flaws. Those need deeper assessment and, for high-value systems, human penetration testing.