Website Security Checklist for Web Designers

Web designers are increasingly expected to ship sites that are not only beautiful and fast, but also secure. Clients don't always ask about HSTS or CSP — but they will absolutely notice when their site shows a "Not Secure" warning, gets flagged by Google Safe Browsing, or fails a procurement security review.

This website security checklist for web designers walks through the practical, ship-ready steps you can take on every project — from SSL setup to security headers, cookies, DNS, and CORS. No vague advice, just things you can implement today.

1. Get SSL/TLS Right (Not Just "On")

Installing a Let's Encrypt cert is the bare minimum. A proper SSL setup means modern protocols, strong ciphers, and no mixed content.

Checklist

• Force HTTPS — redirect all HTTP traffic with a 301 to HTTPS.
• Disable TLS 1.0 and 1.1 — only TLS 1.2 and 1.3 should be enabled.
• Enable HSTS — add Strict-Transport-Security: max-age=31536000; includeSubDomains.
• Fix mixed content — no http:// images, scripts, or iframes on HTTPS pages.
• Auto-renew certificates — set up cron or use a host that handles it.

A common gotcha: enabling HSTS with preload before you're sure every subdomain works on HTTPS. Once you submit to the preload list, rolling back is painful.

2. Configure Security Headers

Security headers are one of the highest-impact, lowest-effort wins. Most can be set in your web server config or via your CDN.

The essentials

1. Strict-Transport-Security — enforces HTTPS.
2. Content-Security-Policy — limits where scripts, styles, and assets can load from (more on this below).
3. X-Content-Type-Options: nosniff — prevents MIME-type sniffing.
4. X-Frame-Options: SAMEORIGIN or CSP frame-ancestors — prevents clickjacking.
5. Referrer-Policy: strict-origin-when-cross-origin — limits what's sent in the Referer header.
6. Permissions-Policy — disables APIs you don't use (camera, geolocation, etc.).

Example Nginx snippet

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

3. Build a Realistic Content Security Policy

CSP is the header most designers skip because it breaks things. But a sensible CSP blocks XSS, rogue scripts, and unauthorised embeds.

Steps to ship a working CSP

• Start in report-only mode using Content-Security-Policy-Report-Only.
• Inventory every external domain — fonts, analytics, embedded videos, chat widgets.
• Avoid 'unsafe-inline' for scripts. Use nonces or hashes instead.
• Set frame-ancestors 'self' to prevent clickjacking.
• Set upgrade-insecure-requests to auto-upgrade legacy URLs.

A starter policy for a typical marketing site:

default-src 'self';
script-src 'self' https://www.googletagmanager.com;
style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
font-src 'self' https://fonts.gstatic.com;
img-src 'self' data: https:;
frame-ancestors 'self';
upgrade-insecure-requests;

Tools like WebSentry will flag CSP weaknesses (missing directives, overly permissive sources, unsafe keywords) so you don't have to manually audit every line.

4. Lock Down Cookies

If your site uses sessions, logins, or carts, cookie attributes matter. Misconfigured cookies are a top cause of session hijacking.

• Secure — only send cookies over HTTPS.
• HttpOnly — block JavaScript access to session cookies.
• SameSite=Lax (or Strict) — mitigate CSRF.
• Short, sensible expiry — don't set 10-year session cookies.
• Cookie banner accuracy — actually block non-essential cookies until consent is given.

5. Harden DNS and Email

DNS is often forgotten by designers, but a weak DNS setup lets attackers spoof emails from your client's domain or hijack subdomains.

Checklist

• SPF record — list authorised mail senders.
• DKIM — sign outgoing email.
• DMARC — start with p=none, monitor, then move to quarantine or reject.
• CAA record — restrict which CAs can issue certs for the domain.
• Remove dangling DNS — delete CNAMEs pointing at decommissioned services (a classic subdomain takeover vector).

6. CORS — Permissive by Default Is Dangerous

If your site exposes any API or JSON endpoints, CORS configuration matters.

• Never use Access-Control-Allow-Origin: * on endpoints that return user data.
• Echo specific allowed origins from a whitelist — don't reflect arbitrary Origin headers.
• Don't combine Allow-Credentials: true with a wildcard origin.
• Restrict Allow-Methods to what you actually use.

7. Keep the Stack Updated

Most real-world site compromises come from outdated CMS plugins, not zero-days.

1. Update WordPress, Drupal, or your CMS core monthly.
2. Audit plugins quarterly — remove anything unused.
3. Subscribe to security advisories for your stack (WPScan, Snyk, GitHub Dependabot).
4. Patch JavaScript dependencies — old jQuery or Bootstrap versions often contain known XSS bugs.

8. Protect Admin and Login Areas

• Enforce strong passwords and 2FA on all admin accounts.
• Rate-limit login attempts (e.g. via Cloudflare or fail2ban).
• Rename or restrict /wp-admin, /admin, or staging URLs by IP where possible.
• Disable directory listings on the server.
• Remove default usernames like admin.

9. Backups and Recovery

Security includes being able to recover. Before launch:

• Set up automated daily backups (database + files) stored off-server.
• Test a restore — an untested backup is not a backup.
• Keep at least 14–30 days of versioned backups.

10. Pre-Launch Security Audit

Before handing a site over to a client, run through this final pass:

1. Site loads cleanly over HTTPS with no mixed content warnings.
2. All security headers present and correctly configured.
3. CSP active (not just report-only) and not breaking pages.
4. Cookies marked Secure, HttpOnly, and SameSite.
5. SPF, DKIM, DMARC, and CAA in place.
6. No exposed .env, .git, or backup files.
7. Admin URLs hardened, 2FA enabled.
8. External scan run with a tool like WebSentry — aim for at least a B grade before launch.

Make This a Repeatable Process

The agencies that ship secure sites consistently aren't smarter — they just have a checklist they actually follow. Save this list, drop it into your project template, and turn each item into a Jira/Linear ticket on every build.

Conclusion

Security doesn't have to slow down your design workflow. Most of the items on this checklist take minutes to implement and pay off for years. Once you've worked through them, run a free scan at websentry.dev to get an A–F grade across SSL, headers, CSP, cookies, DNS, and CORS — and a clear list of anything left to fix before launch.