The Complete Website Security Audit Checklist for Developers (2026)

Running a security audit on your website doesn't require a dedicated security team or a six-figure budget. Most vulnerabilities come down to misconfigurations — missing headers, weak SSL, exposed server information, missing DNS authentication. These are things any developer can check and fix in an afternoon.

This checklist covers the six categories that matter most for web application security. Work through each one, fix what you find, and you'll close the gaps that automated scanners and drive-by attackers exploit first.

Category 1: SSL / TLS Configuration (30 Points)

SSL isn't just about having a certificate. It's about having the right certificate configured correctly.

• Valid certificate: Verify it's not expired and covers all subdomains you serve. Free certificates from Let's Encrypt auto-renew, but misconfigured cron jobs or DNS changes can break renewal silently.
• HTTPS redirect: Every HTTP request should 301 redirect to HTTPS. Test with curl -I http://yoursite.com and verify the Location header points to https://.
• TLS version: TLS 1.2 is the minimum. TLS 1.3 is preferred. If your server still supports TLS 1.0 or 1.1, it's vulnerable to known attacks like POODLE and BEAST.
• Certificate chain: The full chain must be present. Missing intermediate certificates cause trust errors on some devices even when Chrome shows green.
• Mixed content: Every resource on the page (scripts, stylesheets, images, fonts, iframes) must load over HTTPS. A single HTTP resource breaks the green padlock and opens the door to man-in-the-middle attacks.

Category 2: Security Headers (25 Points)

Security headers are instructions your server sends to the browser. They're the single easiest way to harden your site.

• Content-Security-Policy: Whitelist which origins can load scripts, styles, images. Blocks XSS attacks even if your code has vulnerabilities.
• Strict-Transport-Security: Forces HTTPS for all future requests. Set max-age to at least 1 year.
• X-Content-Type-Options: nosniff: Prevents MIME-type confusion attacks.
• X-Frame-Options: Blocks clickjacking by preventing iframe embedding.
• Referrer-Policy: Controls what information leaks when users navigate away.
• Permissions-Policy: Disables browser APIs you don't use (camera, microphone, geolocation).

For a deep dive on each header with copy-paste configs, see our guide on how to check website security headers.

Category 3: Cookie Security (15 Points)

If your site uses cookies (and it almost certainly does), every cookie needs to have the right flags set. Without them, session cookies can be stolen via XSS or leaked over unencrypted connections.

• Secure flag: Ensures the cookie is only sent over HTTPS connections. Without it, the cookie is transmitted in plaintext on HTTP requests.
• HttpOnly flag: Prevents JavaScript from reading the cookie. This stops XSS attacks from stealing session tokens even when they inject script into your page.
• SameSite attribute: Controls when cookies are sent with cross-site requests. Set to Strict or Lax to prevent CSRF attacks.
• No sensitive data in cookies: Don't store user IDs, emails, or permissions directly in cookies. Use opaque session tokens that map to server-side state.

Category 4: Redirect Configuration (10 Points)

Redirects seem trivial, but misconfigurations create security holes.

• HTTP to HTTPS redirect: Must be a 301 (permanent), not a 302 (temporary). Browsers cache 301s, which eliminates the insecure HTTP hop on future visits.
• www normalization: Pick either www or apex domain and redirect the other. Serving the same content on both creates cookie scoping issues and splits SEO authority.
• No open redirect vulnerabilities: Make sure your redirects don't accept arbitrary URLs as parameters. Open redirects are frequently used in phishing attacks.
• Redirect chain length: More than 2 hops indicates a configuration problem. Each hop adds latency and increases the window for interception.

Category 5: DNS & Email Authentication (10 Points)

Your domain's DNS records determine whether attackers can send emails pretending to be you. This is one of the most overlooked areas of web security.

• SPF record: Specifies which mail servers are authorized to send email on behalf of your domain. Without it, anyone can forge emails from your domain.
• DMARC record: Tells receiving servers what to do when SPF/DKIM checks fail (reject, quarantine, or report). Without DMARC, your SPF record is advisory only.
• DKIM: Cryptographic signature on outgoing emails proving they came from your domain and weren't tampered with in transit.
• DNSSEC: Signs your DNS records to prevent cache poisoning. If your registrar supports it, there's no reason not to enable it.

Category 6: Server & Information Leakage (10 Points)

The less an attacker knows about your stack, the harder it is to target you. Information leakage gives away the versions, frameworks, and configurations you're running.

• Server header: Remove or sanitize it. Revealing Apache/2.4.51 tells attackers exactly which CVEs to try.
• X-Powered-By: Remove it entirely. X-Powered-By: Express narrows the attack surface immediately.
• Sensitive paths: Ensure /.env, /.git/config, /phpinfo.php, and /wp-admin/ are not publicly accessible. Exposed environment files are the most common source of leaked credentials.
• Error pages: Custom error pages should never reveal stack traces, database connection strings, or file paths.
• Debug mode: Make sure debug mode is off in production. Django's DEBUG=True, Laravel's APP_DEBUG=true, and Rails' development mode all leak internal details.

Automate This Entire Checklist

Going through this checklist manually is useful for learning, but you shouldn't have to repeat it every time you deploy. WebSentry checks all six categories automatically in under 10 seconds: SSL, headers, cookies, redirects, DNS authentication, and server info leakage. You get an A+ to F grade, a detailed per-check breakdown, and specific advice on what to fix.

On the Pro plan, you can set up ongoing monitoring so you'll get an alert if a deployment accidentally removes a security header or if your SSL certificate is about to expire. No more manual re-auditing.

When to Re-Audit

Security isn't a one-time checklist. Rerun this audit (or your automated scanner) whenever:

• You change hosting providers or CDNs
• You update your web server or framework
• You add a new subdomain
• You change DNS providers
• Major infrastructure changes are deployed
• At least once per quarter as a baseline check

Security configurations drift. What was an A+ last month could be a B today if a middleware update removed a header silently. Continuous monitoring catches these regressions before attackers do.