Most small business sites go live without anyone checking the basics of security. Not because anyone is careless, but because the site “works”, so nobody looks further. This checklist covers nine checks you can run yourself in an afternoon. Every one is non-destructive, and every one comes with a fix.
1. Security headers
What: response headers that tell browsers how to treat your site, such as forcing HTTPS, blocking framing and limiting which scripts can run.
Test: run curl -I https://yoursite.com and look for Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy and Content-Security-Policy.
Fix: add them at your host. On Vercel, for example, in vercel.json:
{ "headers": [{ "source": "/(.*)", "headers": [
{ "key": "Strict-Transport-Security", "value": "max-age=63072000; includeSubDomains" },
{ "key": "X-Content-Type-Options", "value": "nosniff" },
{ "key": "X-Frame-Options", "value": "DENY" },
{ "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
{ "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" }
]}]}Content-Security-Policy is the strongest and the fussiest. Start from default-src 'self', allow only the domains you really load from, and trial it with the Content-Security-Policy-Report-Only header first so you don’t break your own site. Turn on HSTS only once HTTPS works everywhere on your domain.
2. TLS and certificates
What: the encryption behind the padlock. Problems are an expiring certificate, an old protocol version, or HTTP that doesn’t redirect to HTTPS.
Test: use a free TLS tester such as SSL Labs, and check that http:// redirects to https://.
Fix: use a host that renews certificates automatically, and disable obsolete TLS versions (1.0 and 1.1).
3. Rate limiting
What: can your login, checkout or contact form be hit again and again with nothing slowing it down? That’s what lets bots guess passwords and flood forms.
Test: on your own site, send a burst of quick requests to one endpoint and see whether anything ever slows or blocks.
Fix: limit requests at your edge or proxy (your CDN’s rules, or nginx’s limit_req), scoped to the sensitive endpoints. Add a honeypot field or CAPTCHA to public forms.
4. Exposed files
What: files that should never be public: .env secrets, a .git folder, database dumps and backups.
Test: visit /.env, /.git/config, /backup.zip and /db.sql on your own domain. Each should return 404 or 403.
Fix: don’t deploy those files at all, block dotfiles at the server, and keep secrets in your host’s environment variables, not in the project folder.
5. Cookies and sessions
What: login cookies need protective flags. Without them they can be read by scripts or sent over insecure connections.
Test: in your browser’s DevTools, open Application, then Cookies, and check each session cookie for Secure, HttpOnly and SameSite.
Fix:
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax; Path=/6. Brute-force defence
What: does anything stop someone from trying thousands of passwords on a login?
Test: on your own site, with a dummy account, try a handful of wrong passwords and see whether the account locks, a delay kicks in or a challenge appears.
Fix: lock out or throttle after repeated failures, and turn on multi-factor authentication for admin accounts.
7. HTTP methods
What: web servers understand verbs beyond GET and POST. Leaving risky ones such as TRACE, or open PUT and DELETE, enabled by mistake can expose things.
Test: run curl -i -X TRACE https://yoursite.com. It should be rejected (405 or 501).
Fix: allow only the methods each route needs, and refuse the rest.
8. Mixed content
What: an HTTPS page quietly loading an image, script or font over plain HTTP, which undermines the padlock.
Test: open the page with DevTools’ console open. Browsers log “Mixed Content” warnings.
Fix: change those URLs to https://. As a safety net, add upgrade-insecure-requests to your Content-Security-Policy.
9. Email spoofing (SPF, DKIM, DMARC)
What: three DNS records that decide whether someone can send email that looks like it came from your domain.
Test: look up your TXT records, for example nslookup -type=TXT yourdomain.com and nslookup -type=TXT _dmarc.yourdomain.com.
Fix: add SPF and DMARC, and enable DKIM in your email provider (they give you the record to paste). Examples for Google Workspace:
yourdomain.com. TXT "v=spf1 include:_spf.google.com ~all"
_dmarc.yourdomain.com. TXT "v=DMARC1; p=none; rua=mailto:you@yourdomain.com"Start DMARC at p=none to watch reports, then tighten to quarantine or reject once your real mail passes.
What this checklist can’t do
It’s a first pass, not a penetration test. It won’t find flaws in how your application works, such as a checkout that trusts the wrong input. But these nine checks catch the gaps that are cheapest to fix and easiest for others to find.
If you’d rather not do it by hand, TXL Aegis runs these nine non-destructive checks, returns a plain-English grade with the exact fix for each finding, and is included free with any build. Standalone reports are on the pricing page.