Web Server Security Test: The Complete Checklist

A web server security test checks nine things: TLS protocol and cipher configuration, certificate validity, HTTP security headers, Content Security Policy, cookie attributes, software version disclosure, known vulnerabilities in the server and CMS, DNSSEC configuration and unnecessary exposed services and methods. Most of these can be verified for free in under a minute from a browser, and all of them are configuration problems, which means they are fixable without touching application code.

Application vulnerabilities get the attention, but a large share of real-world exposure is plain server configuration: a deprecated TLS version still enabled, a Server header announcing the exact build, a session cookie without the Secure flag, no Content Security Policy at all. None of these require a bug in your code. All of them are visible from outside, which means an attacker sees them before you do.

The advantage is that configuration problems are cheap to fix. This checklist covers what to test, why each item matters, and how to verify it without installing anything.

Web server security test checklist

1. TLS protocols and cipher suites

SSL 3.0, TLS 1.0 and TLS 1.1 are deprecated and should be disabled outright. TLS 1.2 with modern cipher suites is the floor, TLS 1.3 is the target. Cipher suites should provide forward secrecy, so that a future compromise of the private key does not retroactively decrypt captured traffic.

The specific things to remove: RC4, 3DES, export-grade ciphers, anything with NULL or anonymous key exchange, and CBC-mode suites where a modern alternative exists.

Worth adding to the list in 2026: post-quantum readiness. Encrypted traffic captured today can be stored and decrypted later once quantum computers are capable, which makes it a present concern for anything with a long confidentiality horizon.

Test all of this with the free SSL Security Test, which covers web and email servers and reports post-quantum cryptography readiness alongside compliance with PCI DSS, GDPR, HIPAA and NIST.

2. Certificate validity and chain

Three failure modes account for almost every certificate incident. The certificate expires, usually on a host nobody remembered was in scope. The intermediate chain is incomplete, so it works in a desktop browser that caches intermediates and fails on mobile and in API clients. Or the certificate does not cover the hostname actually being used, typically a www or a new subdomain.

All three are invisible until they break. Continuous monitoring is the only real answer, because a certificate that is valid today expires on a date nobody is tracking.

3. HTTP Strict Transport Security

HSTS tells browsers to refuse plain HTTP for your domain entirely. Without it, the very first request a user makes can be intercepted and downgraded before your redirect to HTTPS ever happens.

A reasonable production header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Add includeSubDomains only when you are certain every subdomain serves HTTPS, and treat preload as a one-way door, since removal from the preload list is slow.

4. Content Security Policy

CSP is the single most effective header against cross-site scripting and web skimming, and also the most commonly missing one, because writing a policy that does not break the site takes real work.

A policy is only as good as its strictness. script-src 'self' 'unsafe-inline' provides essentially no protection, because unsafe-inline permits exactly the injection the header exists to stop. Use nonces or hashes instead. A wildcard source such as script-src * is the same problem in a different shape.

Start in report-only mode, collect violations from real traffic, tighten, then enforce. The free Website Security Test evaluates CSP strength rather than just presence, which is the part that actually matters.

5. The rest of the security headers

X-Content-Type-Options: nosniff stops browsers guessing content types, which is how a user-uploaded file becomes executable script.

X-Frame-Options: DENY, or better, frame-ancestors 'none' inside CSP, prevents clickjacking by blocking your pages from being framed.

Referrer-Policy: strict-origin-when-cross-origin stops full URLs, including any identifiers in the path or query string, leaking to third parties through the Referer header.

Permissions-Policy disables browser features the site does not use, such as camera, microphone and geolocation, reducing what injected script can do.

6. Cookie attributes

Every session cookie needs three attributes. Secure prevents transmission over plain HTTP. HttpOnly puts the cookie out of reach of JavaScript, which turns many XSS findings from account takeover into a nuisance. SameSite=Lax or Strict blocks the cross-site request forgery pattern.

This is a one-line change in almost every framework and it is still missing on a large share of production sites.

7. Software version disclosure

Server: Apache/2.4.29 (Ubuntu) and X-Powered-By: PHP/7.2.24 tell an attacker exactly which published exploits to try, before they have sent a single interesting request. Generator meta tags, versioned asset paths and default error pages leak the same information.

Suppressing the headers is not a fix on its own, since obscurity does not patch anything, but it removes you from automated mass-scanning target lists, which is a meaningful reduction in noise.

8. Known vulnerabilities in the server and CMS

Version disclosure only matters because outdated software is so common. A web server, a CMS and its plugins each have their own release cadence, and plugins are usually the weakest link because they are installed once and never reviewed again.

The free Website Security Test identifies outdated and vulnerable software components alongside the header and CSP checks, so this does not need a separate tool.

9. DNSSEC and exposed services

DNSSEC signs DNS responses so they cannot be forged in transit. Without it, an attacker who can manipulate DNS can send your users to their server with a valid certificate they obtained themselves.

Alongside DNS, check what the server exposes that it does not need to: TRACE and other unnecessary HTTP methods, directory listings, .git directories, backup files, admin panels reachable from the public internet, and status or metrics endpoints left open.

Related checks worth running

A web server does not sit alone. Three adjacent tests close the remaining gaps and take a minute each.

The Email Security Test checks the mail side, where TLS configuration and authentication problems are far more common than on the web server, simply because nobody looks.

The Website Privacy Test shows which third-party scripts, trackers and pixels your pages load and where your forms submit, which is directly relevant if the server handles payments.

The Dark Web and Threat Exposure Test looks outward for leaked credentials, squatting domains and phishing sites using your brand, none of which shows up in a server scan.

How to run the test

The fastest path is the free Website Security Test for headers, CSP, DNSSEC, software versions and GDPR and PCI DSS compliance, plus the free SSL Security Test for the encryption layer. Both run from the browser, need no account and return a grade with a downloadable report.

For repeat checks, both tests run from the command line through iwtools, available as a Python script and a Docker image:

./iwtools.py websec --api-key ABCDE-12345-FGHIJ-67890 --recheck -p
https://example.com
./iwtools.py ssl --api-key ABCDE-12345-FGHIJ-67890 --recheck -p example.com:443

Exit code 0 means all configured checks passed, 3 means at least one failed. That is enough to fail a deployment when a header disappears or a weak cipher comes back.

Beyond a one-off test

Configuration drifts. Certificates expire, a plugin update removes a header, a new subdomain launches without any of this applied. A test tells you where you are on one day.

ImmuniWeb® Discovery continuously discovers internet-facing assets, including the ones nobody registered with security, and monitors their configuration, certificates and compliance posture over time. ImmuniWeb® Neuron covers the application layer above the server with a zero false-positive SLA.