The 12-point security checklist that prevents most breaches
Small sites are not breached by sophisticated attacks. Here is the weighted checklist we audit against, with severity and point values.

- Six of the twelve controls are high severity and account for most real incidents.
- Secrets exposed in the client bundle is the single most common finding and the most damaging.
- Unpatched dependencies cause more breaches at small scale than any attack technique.
- Score yourself: under 50 points means significant exposure, over 80 means you are in reasonable shape.
Why the fundamentals matter more than firewalls
Small sites are not targeted by skilled attackers spending weeks on reconnaissance. They are found by automated scanners looking for known vulnerabilities and exposed credentials.
That means the defence is boring and effective: patch things, do not leak secrets, and lock the admin door. The exotic stuff matters at enterprise scale; at your scale, the basics are almost everything.
The six high-severity controls
**HTTPS enforced sitewide (12 pts).** HSTS header present, all HTTP traffic redirecting. Not just available — enforced.
**Security headers set (10 pts).** Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy. Four headers, twenty minutes of work, enormous risk reduction.
**No secrets in the client bundle (14 pts).** API keys, tokens and connection strings must not appear in shipped JavaScript. This is the most common finding we make and the most damaging. Search your built bundle for ‘key’ and ‘secret’ right now.
**Dependencies patched (11 pts).** No known CVEs above medium in your lockfile. Run npm audit or the equivalent monthly, not annually.
**Server-side validation (10 pts).** Client-side validation is a user experience feature, not a security control. Everything must be validated again on the server.
**Admin routes behind auth and 2FA (12 pts).** No unauthenticated admin surface anywhere. Check for forgotten staging environments too.
The medium and low ones
Rate limiting on public endpoints (8), tested backups rather than merely scheduled ones (7), file upload validation by magic bytes not extension (6), DNS records including SPF, DKIM and DMARC (3).
Then the low-severity pair: error pages that leak no stack traces or framework versions (4), and an access review in the last ninety days removing ex-staff and dead integrations (3).
Score yourself honestly
Total available is 100 points. Under 50 puts you in the profile that most compromised small sites share. Fifty to eighty means partial coverage with expensive gaps. Above eighty is reasonable for a site of this size.
The scoring is weighted deliberately. Ticking six low-severity boxes does not compensate for leaving secrets in your bundle.
What this does not cover
This is not penetration testing. It is not compliance certification. It will not protect you against a determined targeted attack.
It covers the fundamentals that account for most real incidents at small scale, and it is the practical layer that should exist before anyone talks to you about SOC 2.
Want this done for you?
We do this work every day across 24 services. Free audit, findings yours either way.
Related questions
How often should I audit?
Quarterly for the automated checks — dependencies, headers, TLS. Annually for a full manual review, or after any significant change to authentication or payments.
Do I need a WAF?
Rarely at small scale, and never as a substitute for the basics. A web application firewall in front of an unpatched application with exposed keys is a lock on a door with no walls.
What is the most common finding?
Secrets in the client bundle, by a wide margin. Usually an API key that a developer put in the front-end code to make something work quickly and never removed.

