Recap: a website security checklist, version 1
Day 7 of our web security series: everything from week one turned into a short checklist you can work through in an afternoon, for visitors and site owners.
A week ago we started with a single question: what actually happens when you open a website? Six posts later, we’ve followed a page load from the address bar to the server and back, and found a security checkpoint at every step.
Today there’s no new theory. Instead, here’s the whole week turned into a checklist. It’s version 1 because it will grow: at the end of each week we’ll add what we’ve learned.
The week in one paragraph
Your browser looks up the site’s address with DNS (Day 5), opens an encrypted HTTPS connection that proves the server’s identity (Day 4), and exchanges HTTP requests and responses (Day 2). The server remembers you with a session cookie (Day 3), and the browser’s same-origin rule keeps other sites from reading your data (Day 6). Day 1 put all of it in one picture.
Each of those layers can be set up well or badly. The checklist below is how you tell the difference.
For site owners: the afternoon checklist
Work through these in order. Most take a few minutes, and none needs special tools.
Domain and DNS
- Your registrar and DNS accounts use a unique password and two-factor login.
- Registrar (transfer) lock is turned on.
- Auto-renew is on and the payment card hasn’t expired.
- No DNS records point to services you’ve stopped using.
- A
CAArecord lists the certificate authority you actually use. - SPF, DKIM and DMARC records exist for your email domain.
HTTPS
- Every page loads over HTTPS.
-
http://requests redirect tohttps://with a 301. - The certificate renews automatically.
- An SSL Labs test gives you an A.
- The
Strict-Transport-Security(HSTS) header is set.
HTTP responses
- Error pages show a plain message, never stack traces, file paths or database errors.
- The server treats every part of a request, including headers and hidden form fields, as untrusted.
- A scan at securityheaders.com shows no surprises.
Sessions and cookies
- The login cookie has
Secure,HttpOnlyandSameSiteset. - A new session ID is issued at login.
- Logging out destroys the session on the server.
- Sessions time out after a sensible period of inactivity.
- Users can log out of all devices.
Cross-origin rules
- If your site sends CORS headers, the allowed origins are an exact list.
- No response combines a wildcard or reflected origin with
Access-Control-Allow-Credentials: true. - Pages can’t be framed by other sites (
frame-ancestors 'self'orX-Frame-Options).
If you can tick every box, your site is already ahead of a large share of the web. If you can’t, don’t worry. Pick the unticked items under Domain and DNS first, because a lost domain is the hardest problem to recover from.
For everyone: the five-minute habits
You don’t need to run a website to use what we covered this week:
- Read the domain name, not just the padlock, before you log in or pay.
- Never click through a certificate warning on a site where you log in or pay.
- Turn on Secure DNS in your browser and Private DNS on your phone.
- Log out of important accounts on shared computers, and use “log out of all devices” if something feels wrong.
- Keep your browser updated and remove extensions you don’t use.
How to use this list
- Do it once, then on a schedule. Settings drift. A record gets added for a test and never removed; a certificate renewal job quietly breaks. Put a reminder in your calendar to run through the list every three months.
- Write down what you find. A simple note with the date and which boxes you ticked makes the next check much faster, and shows what changed.
- Share it. If someone else manages your hosting or domain, send them the list and ask them to tick it with you.
A quick look back at the series so far
| Day | Post | One-line takeaway |
|---|---|---|
| 1 | What happens when you open a website | Every step of a page load is a security checkpoint |
| 2 | HTTP in plain English | Never trust anything the browser sends |
| 3 | Cookies and sessions | The session cookie is the key to the account |
| 4 | HTTPS and the padlock | The padlock protects the connection, not your judgement |
| 5 | DNS | Protect your domain account like your bank account |
| 6 | The same-origin rule | CORS loosens the browser’s protection, so keep it narrow |
Coming up next
Next week is all about logins and accounts. On Day 8 we start with how websites should store passwords: what hashing is, why it matters when a database leaks, and why “we encrypt your password” isn’t quite the right answer.