Web security has a useful property: most of it is observable from the outside. You don't need source-code access to tell whether a site enforces HTTPS, ships a Content Security Policy, or leaves a database port open to the internet — the certificate, the response headers, and the open ports are all visible to anyone who looks. That makes the posture measurable, and measurable means improvable. This page walks the layers and points to the tool for each.
Test your web security
Tools spanning the full posture. Run them together on a domain you own for a complete audit, or individually to chase a specific finding.
TLS and certificates
Every HTTPS connection begins with a TLS handshake, in which the server presents a certificate proving it controls the domain. The certificate chains from the site's leaf certificate through one or more intermediate CAs back to a root in the browser's trust store. If any link is missing, expired, or mis-signed, the browser shows the full-page warning that sends most visitors straight back to the search results.
The things that go wrong are predictable. Expiry is the classic — certificates are deliberately short-lived now (Let's Encrypt issues 90-day certs, and the industry is moving toward 47-day maximums), so a broken renewal cron turns into an outage within weeks. Hostname mismatch happens when the certificate covers example.com but not www.example.com, or when a server is reached by an IP or a CDN bare-host that the cert doesn't list. Weak protocol versions — TLS 1.0 and 1.1 are deprecated and unsafe; 1.2 is the floor and 1.3 the goal. Incomplete chains, where the server forgets to send the intermediate, work in some clients (which cache intermediates) and fail in others, producing the maddening "works on my machine" class of certificate bug.
The SSL Inspector pulls the certificate from Certificate Transparency logs, validates the chain, checks expiry and hostname coverage, reads the live HSTS header, and rolls it all into an A–F grade with a prioritised list of what to fix. Every publicly-trusted certificate is also logged to public CT logs — which our dedicated CT Log Search can use to enumerate every cert ever issued for a domain, a powerful way to catch misissuance and discover forgotten subdomains.
Two details separate a B-grade TLS setup from an A. The cipher suite and key exchange matter: modern configurations prefer forward-secret suites (ECDHE) so that a future compromise of the server's private key can't decrypt past traffic that was captured and stored. And the certificate's signing algorithm should be SHA-256 or better — SHA-1 has been untrusted for years. These are handshake-level properties that a Worker can't fully enumerate without a raw socket, which is an honest limitation of any browser-based checker; for a complete cipher-by-cipher audit, a tool like Qualys SSL Labs or openssl s_client against the live port is the right complement to the certificate-and-header view here.
It's also worth understanding why certificates got short. The shift from one-year to 90-day to soon 47-day lifetimes is deliberate: shorter validity shrinks the window in which a mis-issued or compromised certificate is useful, and it forces automation, which in turn makes renewal a solved background problem rather than an annual fire drill. The practical consequence is that manual certificate management no longer scales — if a human has to remember to renew, it will eventually lapse. The fix every operator should reach for is ACME automation (Let's Encrypt, ZeroSSL, or a cloud provider's managed certificates) with monitoring on the next-expiry date as a backstop.
HTTP security headers
Once TLS is established, the next layer of defence is a set of HTTP response headers that tell the browser how to behave. They cost nothing to add and each one closes a specific class of attack:
- Strict-Transport-Security (HSTS) — forces the browser to use HTTPS for this domain, defeating downgrade and SSL-strip attacks.
- Content-Security-Policy (CSP) — restricts which scripts, styles, and other resources the page may load, the single most effective defence against cross-site scripting.
- X-Frame-Options — controls whether the page can be embedded in an iframe, preventing clickjacking. (Largely superseded by CSP's
frame-ancestors, but still widely honoured.) - X-Content-Type-Options: nosniff — stops the browser from MIME-sniffing a response into a different content type, closing a family of injection tricks.
- Referrer-Policy — limits how much of the referring URL is sent to other origins, a privacy and information-leak control.
- Permissions-Policy — declares which browser features (camera, microphone, geolocation, USB) the page and its frames are allowed to use.
The HTTP Headers tool fetches a URL, inspects every security header, and grades the set A+ → F with specific remediation for whatever's missing or weak. It's the fastest way to take a baseline and track improvement.
A useful mental model: these headers are instructions to the browser, not server-side enforcement. They work because browsers honour them — which means they protect your users, not your server. A header can't stop an attacker from making a raw request; it stops a victim's browser from being turned against them. That framing explains why the set skews toward client-side attack classes (XSS, clickjacking, MIME confusion, mixed content) rather than server-side ones like SQL injection, which no header can touch. The headers are necessary but not sufficient — they're one layer of a defence-in-depth posture, and the most valuable thing the grade gives you is a quick, repeatable baseline you can re-run after every deploy to catch regressions.
HSTS and forcing HTTPS
HSTS deserves its own treatment because of one subtlety: the first visit. A plain HSTS header tells the browser "use HTTPS for the next max-age seconds" — but the very first request to a new domain still happens over HTTP, and a man-in-the-middle can hijack that single unprotected request before HSTS ever takes effect. The preload list closes the gap. It's a list compiled into Chrome (and shipped to Firefox, Safari, and Edge) of domains that are HTTPS-only from the very first byte, no exceptions, no first-visit window.
Getting on the list requires a valid HSTS header with max-age of at least one year (31536000), the includeSubDomains directive, and the preload directive, then a submission at hstspreload.org. The catch worth understanding before you submit: preload is effectively permanent and instant in one direction and slow in the other. Adding a domain is quick; removing it propagates only with browser releases and can take months. If you preload a domain and later need a subdomain to serve plain HTTP, you're stuck. The HSTS Preload Checker validates your header against the exact eligibility rules and reports current preload status before you commit.
Content Security Policy
CSP is the most powerful header and the hardest to get right. At its core it's a whitelist: script-src declares where scripts may come from, style-src for styles, img-src for images, connect-src for fetch/XHR/WebSocket destinations, and so on. A page that loads a script from a source not on the list simply doesn't run it — which is exactly what stops an injected <script> from executing in an XSS attack.
The common misconfigurations defang the policy. unsafe-inline in script-src permits inline scripts, which is most of what XSS injects — its presence largely negates the policy. unsafe-eval re-enables eval() and its relatives. An overly broad source like https: or a wildcard CDN allows far more than intended. The modern approach uses a per-response nonce or hash for inline scripts plus strict-dynamic, and locks object-src and base-uri to 'none'. The CSP Analyzer grades a live policy or one you paste in, flags each weakness, and explains what an attacker could do with it.
The reason CSP is the header most sites get wrong is that retrofitting it onto an existing site is genuinely hard. A real-world page pulls scripts from analytics vendors, ad networks, tag managers, A/B-testing tools, and a half-dozen other third parties, each of which may inject further scripts at runtime. Writing a policy tight enough to stop XSS without breaking legitimate functionality takes iteration. The recommended path is to deploy Content-Security-Policy-Report-Only first — which reports violations without blocking anything — collect the reports for a few weeks to learn what the page actually loads, tighten the policy until the reports go quiet, and only then switch to the enforcing header. Trying to write the perfect policy in one shot almost always breaks something, which is why so many sites either skip CSP or ship a permissive one that doesn't actually defend against much.
Exposed services and vulnerabilities
The layers above concern the web server you intend to expose. The final question is what else is reachable on the host. A database port left open to the internet, an admin panel on a high port, a forgotten service running a version with a known CVE — these are the openings that turn a routine scan into an incident.
An outside-in exposure check answers this for any public IPv4: which ports are open, which CVEs are associated with the detected services, what software the host fingerprints as (via CPE strings), and any tags applied (Tor node, compromised, ICS, and so on). It's a fast view of a host's attack surface — the same first look an attacker takes. Cross-referenced with the certificate and header checks above, it completes the picture: TLS and headers tell you how well the front door is built; the open-port view tells you how many other doors are standing open. (This keyless view was popularised by Shodan's InternetDB, which is licensed for non-commercial use only — so we don't currently offer it as a live lookup here.)
The ports that should set off alarms when exposed to the public internet are the ones meant for internal use: database engines (3306 MySQL, 5432 Postgres, 27017 MongoDB, 6379 Redis, 9200 Elasticsearch), remote-access services (3389 RDP, 5900 VNC), and management interfaces that ended up internet-facing by accident. Many of the largest data breaches of the past decade trace back to exactly this: a database with no authentication, reachable from anywhere, indexed by a scanner within hours of coming online. The CVE list adds the second dimension — a service that's both exposed and running a version with a published, exploitable vulnerability is the highest-priority finding a scan can produce, because exploitation is often fully automated and the window between disclosure and mass-scanning is now measured in hours.
The right response to an exposed-service finding is rarely "patch the CVE" alone. It's to ask why the service is reachable from the public internet at all. Most internal services should sit behind a firewall, a VPN, or a private network segment — exposure is the root cause, the CVE is just the symptom that makes the exposure dangerous today. Reducing attack surface (closing the port, binding to localhost, adding a security group rule) is more durable than chasing individual vulnerabilities, because it protects against the next CVE in that service too.
Common scenarios
"How secure is my site?"
Run these four checks on the same domain in sequence. SSL Inspector for the certificate and TLS posture. HTTP Headers for the overall security-header grade. HSTS Preload Checker to confirm browsers won't downgrade the first visit. CSP Analyzer for the script and resource policy. Passing all four with an A puts you in the top decile of public sites — most production sites fail at least one, usually CSP.
"What's exposed on this server?"
An outside-in exposure check answers this: every open port, the software fingerprints, and any CVEs tied to those services. If you see a database port (3306, 5432, 27017, 6379), a message-queue port, or an admin interface reachable from the public internet, that's the first thing to firewall — the outside-in view shows what the world can actually reach, which is often broader than the intended configuration. We don't currently offer a live open-port lookup (Shodan's InternetDB, which powers this view, is non-commercial-only); our IOC Enrichment report covers an IP's ASN, geo, Tor, and blacklist signals in the meantime.
"Why is my certificate failing?"
The SSL Inspector pinpoints the cause. Expired? Renew — and fix the automation that should have. Hostname mismatch? The cert doesn't list the name you're reaching it by; reissue with the right SANs. Chain incomplete? The server isn't sending the intermediate — add it to the server's certificate bundle. Untrusted issuer? The cert is self-signed or from a CA not in public trust stores, so it'll never validate in a browser without manual trust. The grade card calls out which of these applies and what the fix is.
Learn more
The deep-dive posts below cover the protocols and headers in detail, with the operational gotchas that surface in real deployments.