Website Security Audit: HTTP Headers, TLS, CMS, Mail DNS & CVEs

A passive security audit checks the publicly observable security posture of any website — without sending malicious payloads or probing for vulnerabilities. This guide walks through every check our Security Audit tool runs, why each one matters, and exactly how to fix any that fail. Pair this guide with the example report to see a real audit output.

What is a passive security audit?

A passive audit only inspects information your site already exposes to any visitor: HTTP response headers, the TLS handshake, public DNS records, and the rendered HTML. Nothing is sent that could be considered an attack. That makes it safe to run against any domain you have permission to scan, including production, and means it will not trigger your WAF or intrusion detection.

This audit covers 23 individual checks across 9 families. Each check is tagged with the relevant OWASP Top 10 category and CWE identifier so findings map cleanly onto the standard vulnerability taxonomy used by security teams.

HTTP Security Headers

Six response headers do most of the heavy lifting for browser-side protection. They cost nothing to deploy, work in every modern browser, and stop entire classes of attack.

Content-Security-Policy (CSP)

CSP tells the browser which sources are allowed to load scripts, stylesheets, fonts, frames and other resources. A well-tuned CSP is the single strongest defence against cross-site scripting (XSS), which remains one of the most common web vulnerabilities. Start strict and loosen as needed:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'self'

Strict-Transport-Security (HSTS)

HSTS tells browsers to refuse to connect to your site over plain HTTP, even if the user types http:// in the address bar. This closes the small window where a man-in-the-middle attacker could downgrade the first request before the redirect to HTTPS.

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

X-Frame-Options / CSP frame-ancestors

Stops other sites embedding your pages in an iframe. The classic clickjacking defence — without it, an attacker can overlay your login form inside a malicious page and steal credentials. Either header passes the check:

X-Frame-Options: SAMEORIGIN

Or, preferred:

Content-Security-Policy: frame-ancestors 'self'

X-Content-Type-Options

Stops browsers second-guessing the Content-Type header through MIME sniffing. Without it, a file you serve as text/plain could be interpreted as JavaScript and executed. One line, one config option:

X-Content-Type-Options: nosniff

Referrer-Policy

Controls how much of the originating URL is sent in the Referer header when a user clicks a link to another site. The right setting protects user privacy and prevents leaking session-bearing URLs:

Referrer-Policy: strict-origin-when-cross-origin

Permissions-Policy

Disables browser features that your site does not need. If you do not use the camera, microphone or geolocation, deny them and remove an entire class of supply-chain risk from compromised third-party scripts:

Permissions-Policy: geolocation=(), microphone=(), camera=(), payment=()

TLS / SSL Configuration

The TLS check opens an actual handshake to port 443 and inspects the certificate plus the negotiated protocol. Three things must be true:

Cookie Security Flags

Every Set-Cookie response should set three attributes. If a site sets cookies on the homepage, the audit checks all of them:

Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax; Path=/

• Secure — cookie is only sent over HTTPS
• HttpOnly — JavaScript cannot read the cookie (defence against XSS-based session theft)
• SameSite=Lax or Strict — defends against CSRF

Mixed Content

If your page is served over HTTPS but loads any http:// resources, browsers will either block them (modern behaviour) or downgrade the connection (older behaviour). Either way, you lose. The audit scans the homepage HTML for any script, link, img, iframe or source tag pointing at an unencrypted URL.

Server Fingerprinting

Two response headers commonly leak version information that makes an attacker's job easier:

Server: nginx/1.18.0
X-Powered-By: PHP/7.4.0

An attacker now knows your nginx and PHP versions before lifting a finger. Strip them. In nginx:

server_tokens off;
fastcgi_hide_header X-Powered-By;
proxy_hide_header X-Powered-By;

In Apache:

ServerTokens Prod
ServerSignature Off
Header unset X-Powered-By

In PHP, also set expose_php = Off in php.ini.

Known CVEs (NVD)

When the audit identifies a software version from the Server or X-Powered-By header, or a CMS generator meta tag, it builds a CPE 2.3 identifier and queries the National Vulnerability Database for matching CVEs.

Results are cached for 24 hours per CPE to keep scans fast and avoid hammering NVD. If your site does not expose any version strings, this check passes by default — no fingerprint, nothing to look up. That is the desired outcome.

CMS Detection

The audit looks for three signals on the homepage:

• <meta name="generator" content="WordPress 6.4.2"> — most common
• The X-Generator response header (used by Drupal)
• Path patterns like /wp-content/, /wp-includes/ or /sites/default/

Detection itself is not a fail. The fail is when the generator tag exposes the exact version, because that turns CMS detection into a one-step CVE lookup for an attacker. Remove the generator meta:

// WordPress functions.php
remove_action('wp_head', 'wp_generator');

Mail Security DNS

Even sites that do not send email get impersonated. Without SPF, DKIM and DMARC records, anyone can send mail from @yourdomain.com and have it land in inboxes. The audit checks three TXT records on the apex of your domain (the www. prefix is stripped automatically):

# SPF (TXT on apex)
v=spf1 include:_spf.google.com -all

# DMARC (TXT on _dmarc.yourdomain.com)
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

# DKIM (TXT on <selector>._domainkey.yourdomain.com)
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN...

DKIM uses per-vendor selectors so the audit probes the most common ones (default, google, selector1, selector2, k1, s1, s2, mail). If your provider uses a different selector the check may show no result even though DKIM is configured — check your email provider's documentation.

robots.txt & security.txt

Two standard well-known files round out the audit.

robots.txt

Crawlers expect /robots.txt to exist. Even an empty file is preferable to a 404, which floods server logs with crawler errors and signals an under-maintained site.

security.txt (RFC 9116)

Defines how security researchers should report vulnerabilities they find on your site. Publish it at /.well-known/security.txt:

Contact: mailto:security@yourdomain.com
Expires: 2027-12-31T23:59:59.000Z
Policy: https://yourdomain.com/security-policy.html
Preferred-Languages: en

Required fields are Contact and Expires. Everything else is optional but useful. Without security.txt a researcher who finds a bug has no obvious place to report it, and may resort to public disclosure.

How the score is calculated

Each check has a weight reflecting its impact. TLS validity and protocol weight heaviest (10 and 8 points respectively), header checks are mid-weight (4–8), and informational checks like robots.txt presence are light (2). Warnings (for example a certificate expiring in 30 days, or a CMS exposing its version) score half-credit rather than zero. The total weight is 109 points, normalised to a score out of 100.

Frequently Asked Questions