What should be on a website security checklist?

Focus on what an outsider can see and reach. First, transport: serve every page over HTTPS, redirect HTTP, use a valid auto-renewing certificate, and add HSTS once HTTPS is solid. Second, the core security headers — Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, a frame-ancestors or X-Frame-Options control, and Referrer-Policy. Third, exposed files: no public .git directory, no .env or config served as text, no backup archives in the web root, and no openly reachable admin or staging surfaces. Fourth, email authentication with SPF, DKIM, and DMARC so nobody can spoof your domain. Finally, maintenance habits — patch promptly, apply least privilege, keep tested backups, and monitor for change. Work top-down by impact and fix anything critical before anything cosmetic. A useful test for each item is whether it is checkable from outside without credentials: if an anonymous request can reach it, so can an attacker. Some items also live at the DNS or hosting layer, not in your code.

How often should I run a security check?

Run a full check on a regular cadence and again after any meaningful change. A monthly or quarterly pass catches the things that drift on their own: a certificate creeping toward expiry, a newly opened port, or a header that a framework upgrade quietly dropped. On top of that, re-check immediately after you deploy, change hosting, install or update a plugin, or migrate a domain, because those are exactly the moments a backup file or a staging copy slips into the web root. A passive external scan is cheap enough to run often, so treat it like a smoke test rather than an annual audit. The goal is to shorten the window between a regression appearing and you noticing it — most exposures are far cheaper to fix the day they appear than the day someone else finds them.

What's the single most important item?

If you can only do one thing, make sure nothing private is publicly reachable — no exposed .git directory, .env file, or downloadable backup. Those are the findings that turn a quiet site into a full compromise, because they can hand over your source code, your secrets, or your entire database in a single request, with no exploitation skill required. Transport security comes a very close second: HTTPS everywhere with a valid certificate, since it underpins everything else. The reason exposed files edge ahead is impact versus effort. A missing header weakens a defence; a public backup is the breach itself. Both belong on the list, but when you are triaging, confirm there is nothing critical sitting in the open before you spend time tuning a content security policy.

How do I check all of this quickly?

Run a passive external scan rather than checking each item by hand. A scanner requests your site the way any visitor would, then reports on transport, the core security headers, common exposed paths, and your published email authentication records — all in one pass, without touching your server or needing any credentials. That gives you an A–F grade per area and a prioritised list of what to fix first, which is far faster and more reliable than manually testing a dozen URLs and reading raw headers. Use SecScan's free website security score to get the full picture in seconds, then drill into the specific guides — security headers, HSTS, email authentication — for the items it flags. Re-run the scan after each fix to confirm the change landed and didn't break anything adjacent.

Website Security Checklist (2026) — The Essentials That Matter

Security work has a way of expanding to fill whatever time you give it. A checklist keeps that energy pointed at the things that actually move your risk down.

The list below is organised by what an outside observer can see and reach without any special access — the same surface an automated scanner or an opportunistic attacker probes first. Work through it top-down by impact, fix anything critical before anything cosmetic, and re-check after every change so you can confirm the fix landed.

For the site owner (plain English)

If you are not technical, here is the short version. This checklist is a list of things a stranger can see about your site from the outside — whether it is encrypted, what safety instructions it sends to browsers, and whether any private files were left in the open. None of it requires logging in or attacking anything. The order is deliberate: the top items prevent the worst outcomes. You do not have to do it all today. Hand the list to whoever maintains your site, or run the free scan below and let it tell you which few items actually apply to you. The simplest path is to fix anything marked critical first, then work down.

Is your transport layer locked down (HTTPS, certificates, HSTS)?

Everything else assumes the connection between your visitor and your server is private and authentic. If that assumption is wrong, headers and cookies and login forms are all negotiable. Start here.

Serve every page over HTTPS. Mixed content — an HTTPS page pulling a script over plain HTTP — quietly reopens the door you just closed. Why: a single insecure asset can be tampered with in transit.
Redirect HTTP to HTTPS with a 301. Why: visitors who type the bare domain should never land on the unencrypted version even for a moment.
Use a valid, trusted certificate with auto-renewal. An expired certificate breaks the site for everyone and trains users to click through warnings. Why: most outages here are renewal failures, not attacks — automate it and stop thinking about it. Confirm details with the SSL checker.
Send HSTS once HTTPS is solid. The Strict-Transport-Security header tells browsers to refuse plain HTTP for your domain. Why: it closes the brief redirect window attackers can exploit. See the HSTS and preload guide before you set a long max-age or submit to the preload list.

Order matters: get HTTPS working everywhere first, then layer HSTS on top. Sending HSTS while some assets are still HTTP-only will simply break them.

Which security headers should you set?

Response headers are instructions you hand the browser about how to treat your pages. A handful of them meaningfully shrink your attack surface and cost nothing but configuration. The OWASP Secure Headers Project maintains the canonical guidance on which ones to set and why.

Content-Security-Policy. Why: it constrains where scripts, styles, and frames may load from, which is your strongest lever against cross-site scripting. Start in report-only mode so you can tune it without breaking the page.
Strict-Transport-Security. Why: covered above — it belongs on every HTTPS site.
X-Content-Type-Options: nosniff. Why: stops the browser from second-guessing a file's declared type and executing something you served as data.
X-Frame-Options or a CSP frame-ancestors directive. Why: prevents your pages from being embedded in a hostile frame for clickjacking.
Referrer-Policy. Why: keeps full URLs (which can carry tokens or internal paths) from leaking to third parties.

A reasonable starting set looks like this:

Strict-Transport-Security: max-age=63072000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: default-src 'self'
X-Frame-Options: SAMEORIGIN

Treat the CSP line as a sketch, not a paste-in — every site needs its own sources. The security headers guide walks through each one, and the header checker shows what you're sending today.

Which files and paths should never be public?

Some of the most damaging findings are not subtle vulnerabilities — they are files that were never meant to be public and got deployed anyway. They are cheap to find and cheap to fix, which is exactly why they should be near the top of your list.

No public .git directory. Why: a reachable /.git/ can let someone reconstruct your entire source tree, including secrets in old commits.
No .env or config files served as text. Why: these routinely hold database passwords, API keys, and signing secrets.
No backup or archive files in the web root — .bak, .sql, .zip, site.tar.gz. Why: a downloadable backup hands over your whole application and often its data.
Admin and staging surfaces are not openly reachable. Why: login panels and half-finished staging copies are favourite targets — restrict them by IP, auth, or by not deploying them at all.
Directory listing is disabled. Why: an open index lets anyone browse files you forgot were there.

Build a habit, not a one-time sweep: add a deploy step or a small scan that checks these paths every release, because the file you delete today reappears the day someone restores from a hurried backup.

How do you authenticate your email?

Your domain's reputation is part of its security posture. Without published authentication records, anyone can send mail that appears to come from you, and your legitimate mail is more likely to land in spam.

Publish an SPF record. Why: it lists the servers allowed to send mail for your domain, so receivers can reject the rest.
Sign mail with DKIM. Why: a cryptographic signature lets receivers confirm a message really came from you and was not altered.
Set a DMARC policy. Why: it ties SPF and DKIM together and tells receivers what to do with mail that fails — start at p=none to gather reports, then tighten toward quarantine and reject.

The email authentication guide explains how the three records reinforce each other, and the DMARC checker shows what your domain currently publishes.

What ongoing maintenance keeps a site secure?

A site that was secure last quarter is not necessarily secure now. The items below are habits rather than settings — they keep the rest of the list from quietly drifting out of compliance.

Keep software patched. Why: most real-world compromises ride in on a known, already-fixed flaw in a CMS, plugin, or library — patching closes the door before it's tried.
Apply least privilege. Why: every account, key, and integration should have the narrowest access that still works, so one stolen credential does limited damage.
Keep tested, offline backups. Why: a backup you have never restored is a guess; a recent, verified one is your recovery plan.
Monitor for change. Why: certificate expiry, a new open port, or a regressed header all happen between releases — periodic re-checks catch them while they're cheap to fix.

A high overall score can still hide one critical exposure. A site that scores in the A range on headers and TLS but leaves a public /.git/ directory is not an A-grade site — it is a one-finding breach waiting to be reported. Fix anything critical first; an average rewards you for the things you got right and says nothing about the single item that can sink you.

Verify with a score

The fastest way to turn this checklist into a concrete to-do list is to measure your site as it stands today. A passive external scan checks transport, headers, exposed paths, and email authentication from the outside — the same view an attacker has — and grades each area so you know where to start and, just as usefully, what you can stop worrying about.

Run every item on this checklist against your real site in one pass.

Get your free A–F security score →

Re-run it after each fix. Watching a grade move is the cleanest confirmation that a change did what you intended — and the cleanest way to catch a fix that silently broke something else.

Where to go next

For the reasoning behind each area, read the pillar: the complete website security guide. If your score is already in hand and you want a prioritised plan to raise it, see how to improve your security score.

Website Security Checklist (2026)