Website Security Scanner
Complete web security audit for any domain — TLS certificate, HSTS, security headers, Content Security Policy, CAA records, and redirect hygiene checked in one scan. Get an overall score, letter grade, and prioritised action plan. Built for IT admins, MSPs, and security teams.
Scanning …
How the Website Security Scanner works
Enter any domain and the scanner performs five parallel checks simultaneously, then combines the results into a unified scored report:
- Transport Security — Performs a raw TLS handshake to retrieve the certificate chain, validity dates, key type and strength, TLS version negotiated, and chain completeness. Simultaneously fetches the HTTPS response to check the Strict-Transport-Security header, max-age, includeSubDomains, and preload directive.
- Security Headers — Fetches the site with a browser-like GET request and analyzes all security-relevant response headers: CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COOP, COEP, and CORP.
- Content Security Policy — Parses the CSP header if present and deeply analyzes all directives for unsafe keywords ('unsafe-inline', 'unsafe-eval', wildcards), missing critical directives (object-src, base-uri, frame-ancestors), and reporting configuration.
- CAA Records — Queries CAA DNS records via DNS-over-HTTPS to identify which Certificate Authorities are authorized to issue certificates, whether wildcard issuance is restricted, and whether iodef violation reporting is configured.
- Redirect Hygiene — Tests all four entry points (http/https × bare/www) and follows each redirect chain to detect HTTPS enforcement, canonicalization, redirect loops, HTTPS→HTTP downgrades, and excessive hop counts.
The overall score uses a weighted model: CSP (25%), TLS/Certificate (20%), Security Headers (20%), HSTS (15%), Redirects (10%), CAA (10%). Each category is scored independently on a 0–100 scale before weighting.
Who uses the Website Security Scanner
- MSP client onboarding — run before a kickoff meeting to identify web security gaps and generate a plain-text report for the client with specific, prioritised remediation steps
- Security reviews and audits — quickly assess any web property's security posture as part of a broader security assessment or compliance review
- Post-deployment validation — confirm that new security headers, TLS configuration, or HSTS policy survived a server migration or CDN change
- Certificate management — monitor certificate expiry across multiple domains before they cause browser warnings or outages
- Hardening checklists — verify that CSP, security headers, HSTS, and CAA controls are in place as part of CIS Benchmark or OWASP hardening recommendations
- Vendor risk assessment — quickly evaluate the web security maturity of suppliers, partners, and SaaS vendors before sharing data or integrating systems
HTTPS and TLS explained
HTTPS (HyperText Transfer Protocol Secure) is the encrypted version of HTTP. It uses TLS (Transport Layer Security) to authenticate the server's identity and encrypt all data in transit between the browser and the server. Without HTTPS, every request and response — including passwords, cookies, and personal information — is transmitted in plaintext and can be read or modified by anyone on the same network.
A TLS certificate is issued by a Certificate Authority (CA) and contains the server's public key, the domain name(s) it covers, the issuing CA, and the validity period. When a browser connects to an HTTPS site, it verifies the certificate is trusted (signed by a CA in the browser's trust store), is within its validity period, and matches the hostname being accessed. An expired, self-signed, or domain-mismatched certificate causes browsers to display a blocking security warning.
TLS 1.3 (2018) and TLS 1.2 are the only versions in active use. TLS 1.0 and 1.1 are deprecated and disabled in all modern browsers due to known weaknesses (BEAST, POODLE, CRIME). Server configuration should explicitly disable TLS 1.0 and 1.1 and prefer TLS 1.3 where supported.
HSTS: enforcing HTTPS from the browser
Even if a site redirects all HTTP traffic to HTTPS, a user who types the domain into a browser without specifying https:// will start with a plain HTTP request that the server then redirects. That first unencrypted request is a window for a network attacker to intercept the connection and strip the HTTPS redirect — an SSL stripping attack.
HTTP Strict Transport Security (HSTS) closes this window. When a browser receives an HSTS header from a site, it caches a policy that says "always connect to this site over HTTPS for the next N seconds." On subsequent visits, the browser never makes the initial HTTP request — it upgrades to HTTPS internally before sending any data. The max-age directive controls how long the policy is cached; industry standard is 31536000 (1 year).
includeSubDomains extends the policy to all subdomains — important for preventing attacks on subdomains that might still be accessible over HTTP. The preload directive, combined with a max-age of at least one year and includeSubDomains, makes a domain eligible for the HSTS preload list — a database built into browsers that enforces HTTPS before the very first connection, eliminating the initial HTTP window entirely.
Security headers: browser-level protection controls
HTTP response headers instruct the browser how to handle a page and its resources. Security headers are a set of response headers that activate built-in browser security features. They are typically added in your web server, CDN, or application framework configuration and require no changes to application code.
- Content-Security-Policy — The most impactful security header. Controls which scripts, styles, images, and other resources the browser may load. A well-configured CSP prevents XSS attacks by ensuring that even if an attacker injects malicious code, the browser refuses to execute it.
- Strict-Transport-Security — Instructs browsers to only connect over HTTPS for a specified duration. Prevents SSL stripping attacks on repeat visits.
- X-Frame-Options — Prevents the page from being embedded in iframes on other origins, blocking clickjacking attacks where users are tricked into clicking on invisible elements.
- X-Content-Type-Options: nosniff — Prevents browsers from guessing content types. Stops non-script resources from being executed as scripts.
- Referrer-Policy — Controls how much referrer information is included when the browser follows links to other sites. Strict policies prevent internal URLs and session parameters from leaking to external analytics and ad networks.
- Permissions-Policy — Restricts which browser APIs (camera, microphone, geolocation, payment) the page can access, limiting the attack surface if XSS occurs.
Content Security Policy and XSS protection
Cross-site scripting (XSS) is consistently one of the most common and impactful web vulnerabilities. An XSS attack injects malicious script code into a trusted page — where it can steal session cookies, capture keystrokes, redirect users to phishing sites, or make API calls on the victim's behalf with full page permissions.
A Content Security Policy mitigates XSS by telling the browser exactly which scripts are trusted. The most common CSP weakness is 'unsafe-inline' in the script-src directive, which allows any inline <script> block to execute — including injected attacker code. The modern replacement is nonces: a unique, random token generated per request, added to each <script> tag as an attribute, and included in the CSP. The browser only executes scripts whose nonce matches the CSP policy — injected scripts without the nonce are blocked.
Other critical CSP directives include object-src 'none' (blocks browser plugin attacks), base-uri 'self' (prevents base tag injection), and frame-ancestors (supersedes X-Frame-Options for clickjacking protection in modern browsers).
Certificate Authority Authorization (CAA)
CAA records are DNS records (type 257) that specify which Certificate Authorities are permitted to issue TLS certificates for a domain. Before a CA issues a certificate, it is required (per CA/Browser Forum Baseline Requirements) to check the domain's CAA records. If CAA records exist and the CA is not listed, the CA must refuse the issuance request.
Without CAA records, any publicly trusted CA can issue a certificate for your domain. While formal misissuance events are rare, they do occur — and a misissued certificate is essentially as dangerous as a compromised private key. CAA records add a layer of defense against both fraudulent certificate requests and CA infrastructure compromises.
Three CAA record types are relevant: issue restricts which CAs can issue standard certificates; issuewild restricts wildcard certificate issuance separately; and iodef specifies a URL or email address where CAs should send violation reports when they receive an unauthorized issuance request for your domain. The iodef record is an early warning mechanism and is free to configure.
HTTP redirects and canonical URL hygiene
Every website has multiple potential entry points: http://, https://, http://www., and https://www.. How these four variants are handled has security, performance, and SEO implications. A well-configured site redirects all non-canonical variants to a single canonical URL using 301 (Moved Permanently) redirects, which are cached by browsers and search engine crawlers.
HTTPS enforcement is the most critical redirect consideration. Any HTTP variant that does not redirect to HTTPS leaves visitors on unencrypted connections. A 301 redirect means browsers cache the upgrade — on future visits they go directly to HTTPS without making the initial HTTP request. An HTTPS downgrade redirect (https:// → http://) is a serious misconfiguration that should be remediated immediately.
Redirect chain length matters for performance. Each redirect adds 100–300ms of round-trip latency. Best practice is to chain at most 2 hops per entry point: one to enforce HTTPS, one to enforce the canonical hostname. Longer chains accumulate latency and can confuse crawlers. Redirect loops — where URL A redirects to B which redirects back to A — make the URL completely unreachable.
How MSPs use the Website Security Scanner
Managed Service Providers and IT consultants can use the Website Security Scanner as a standard part of client onboarding and quarterly review workflows:
- Client onboarding — run a scan on the client's primary domain before the first meeting. Use the score and top findings to structure the security discussion and generate an initial remediation priority list
- Shareable reports — use the
?domain=clientdomain.comURL parameter to create a permanent link to the client's scan. Share the link in tickets, emails, or client portals - One-click report export — Copy Executive Summary produces a plain-text snapshot with score, grade, status indicators, top findings, and recommendations suitable for client emails. Copy Full Report exports everything including all findings, category scores, and deep links
- Quarterly reviews — re-run scans after any infrastructure change and on a regular cadence to catch certificate expiry, configuration drift, and new security gaps before they cause incidents
- Scoping remediation — each recommendation includes impact level, difficulty, and estimated effort — making it easy to build a remediation plan with realistic time estimates for client proposals
Web Security Guidance
Frequently Asked Questions
Everything you need to know about HTTPS, HSTS, security headers, Content Security Policy, CAA records, and web application security hardening.
What does the Website Security Scanner check?
Five parallel checks: TLS/SSL certificate validity, key strength, chain completeness, and TLS version; HTTP security headers including CSP, HSTS, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy; Content Security Policy deep analysis for unsafe keywords and missing directives; CAA DNS records to verify certificate issuance restrictions; and HTTP redirect chains from all four entry points (http/https × bare/www). Results are scored using weighted category scores and combined into an overall A+–F grade.
What is HSTS and why does it matter?
HSTS (HTTP Strict Transport Security) is a response header that tells browsers to always use HTTPS when connecting to your site. Even if a site redirects HTTP to HTTPS, the initial unencrypted request is a window for SSL stripping attacks. HSTS caches the HTTPS-only policy in the browser for the duration of max-age, so future visits skip the HTTP request entirely. Add includeSubDomains to protect all subdomains, and preload to qualify for browser preload lists that enforce HTTPS before the first connection.
Why is a Content Security Policy so important?
CSP is the primary browser-level defence against cross-site scripting (XSS) — consistently one of the most common and impactful web vulnerabilities. Without a CSP, any script injected into your page by an attacker executes with full page privileges. A strict CSP using nonces or hashes means only explicitly trusted scripts run. CSP scores 25% of the overall website security score because XSS is such a widespread attack vector and CSP is the most impactful single control.
What does 'unsafe-inline' mean in a CSP?
'unsafe-inline' in script-src allows all inline <script> blocks and event handlers to execute — including injected attacker code. This effectively disables XSS protection. Replace 'unsafe-inline' with per-request nonces: generate a unique random token per response, add it as an attribute on each <script> tag, and include 'nonce-{token}' in the CSP. Add 'strict-dynamic' to transitively trust scripts loaded by nonce-bearing scripts.
What are CAA records and should I add them?
CAA records specify which Certificate Authorities may issue TLS certificates for your domain. Without them, any of the 100+ publicly trusted CAs can issue a certificate. While misissuance is rare, it does occur — a misissued certificate allows an attacker to perform man-in-the-middle attacks on your HTTPS traffic. Adding CAA records restricts issuance to your CA of choice. Add an iodef record to receive alerts when a CA detects an unauthorized issuance request. Most DNS providers support CAA records through their control panel.
What is a redirect loop and how do I fix it?
A redirect loop occurs when URLs redirect in a cycle — A redirects to B, B redirects back to A. The URL is permanently unreachable. Common causes: conflicting www ↔ non-www rules that fire in both directions, Cloudflare Page Rules that conflict with origin rewrites, or .htaccess rules applied to the redirect destination. Debug by disabling redirect rules one at a time in your web server, CDN, and application until the loop breaks.
What does 'probe blocked' mean in the TLS check?
The TLS certificate check uses a raw TCP socket to port 443. Cloudflare-proxied domains and CDN-fronted hosts route connections through Cloudflare IP ranges, which the Cloudflare runtime explicitly blocks for outbound connections — a documented platform behaviour. When this occurs, the scanner falls back to an HTTPS fetch to retrieve HSTS data. The HSTS score is computed from the fetch result. For full certificate details, use your browser's padlock, the SSL/TLS Certificate Checker tool, or a desktop SSL inspection tool.
How is the overall score calculated?
The overall score is a weighted composite: CSP (25%), TLS/Certificate (20%), Security Headers (20%), HSTS (15%), Redirects (10%), CAA (10%). CSP carries the highest weight because XSS attacks are the most common web application vulnerability. TLS and headers carry equal weight as foundational controls. HSTS is scored separately from general headers to reflect its specific role in HTTPS enforcement. Redirects and CAA carry lower weights as governance controls rather than primary attack vectors. Grades run from A+ (95+) down to F (below 40).
Should I submit my domain to the HSTS preload list?
The HSTS preload list is a database built into browsers (Chrome, Firefox, Safari, Edge) that enforces HTTPS before the first connection — eliminating the SSL stripping window entirely. Eligibility requires max-age=31536000, includeSubDomains, and the preload directive. Submit at hstspreload.org. Important caveat: preloading is hard to reverse — removing a domain requires the browser to ship an update, which takes months. Ensure all subdomains are permanently HTTPS-capable before submitting.
What does an incomplete certificate chain mean?
An incomplete chain means the server only sends the leaf (end-entity) certificate without the intermediate CA certificates connecting it to a trusted root. Modern browsers often download missing intermediates automatically via AIA URLs, but API clients, older browsers, and server-to-server connections may fail. Fix: configure your web server with the full chain file (leaf + all intermediates concatenated). Let's Encrypt provides fullchain.pem which includes the correct chain. Test with an external SSL checker after updating.
How many redirect hops is acceptable?
Best practice is at most 2 hops per entry point: one to enforce HTTPS, one to enforce the canonical hostname (e.g. www vs. non-www). Each redirect adds 100–300ms round-trip latency. For http://example.com/ → https://example.com/ → https://www.example.com/ that is 2 hops, which is acceptable. Ideally, direct http:// requests to the canonical https:// URL in one hop. Sites with 4+ hops on any path should audit and consolidate their redirect rules.
Can MSPs use this report for client security reviews?
Yes. Use the shareable URL (?domain=clientdomain.com) to create a direct link to any client's scan. Copy Executive Summary produces a plain-text report with score, grade, status indicators, top findings, and prioritised recommendations — suitable for client emails, tickets, and proposals. Copy Full Report exports all findings, category scores, recommendations with effort estimates, and deep links to individual tools with the domain pre-filled. Each recommendation includes impact, difficulty, and estimated effort for scoping remediation work.
What is the difference between Website Security Scanner and Domain Intelligence Scanner?
The Domain Intelligence Scanner is a broad domain assessment — DNS configuration, DNSSEC, email authentication (SPF, DKIM, DMARC), and a high-level view of TLS and security headers. The Website Security Scanner is a deep-dive specifically into web security controls: detailed TLS/HSTS analysis, full security headers check, deep CSP analysis with directive-level detail, CAA governance, and complete redirect chain testing. The two tools complement each other — run Domain Intelligence for a full domain picture, and Website Security Scanner for focused web application security.
How often should I scan?
Scan any time you change TLS certificates, security header configuration, DNS records, or web server settings. Certificate renewals, CDN migrations, server upgrades, and CMS updates can all affect your security posture. For production sites, monthly scans catch certificate expiry early and identify configuration drift. MSPs typically scan client sites at onboarding, after any infrastructure change, and quarterly for ongoing monitoring. Use the shareable URL to bookmark each client's scan for quick re-checks.