Website Security Check
Enter a domain to see what your site exposes to the internet. The check only uses what the server sends back.
The report shows what an external client can see from your site at the time of the check. It does not inspect your configuration files.
If the site is behind a CDN or WAF, what the check reads belongs to that layer rather than the origin server. The report names the intermediary it detected, and every remediation says which layer to apply it at.
What is checked
- HTTP security headers: HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Cache-Control, CORS, cookie flags, the redirect from port 80, and server version disclosure.
- SSL/TLS: accepted protocol versions, cipher suites, downgrade protection, renegotiation, compression, and certificate properties including validity, chain, hostname coverage, signature algorithm, and key size.
- Post-quantum readiness: the key exchange the server negotiates, reported per address.
PQC Readiness
No quantum computer breaks TLS today. The concern is encrypted traffic captured now and decrypted later, which is why key exchange upgrades first.
The check opens a TLS 1.3 connection and records the key-exchange group the server selects, one row per address. A domain can resolve to several servers that do not share a TLS configuration, so the report lists every address it reached: one status when they agree, and which addresses lag when they do not.
A hybrid group such as X25519MLKEM768, or a pure ML-KEM group, passes. The status comes from the group negotiated in that handshake, never from the list the server advertises, so a server that supports a post-quantum group but selects a classical one during the check does not pass.
How to read the result
Findings use three statuses:
- Needs fixing: checked and the issue was found.
- Passed: checked and the issue was not found.
- Not assessed: no verdict was possible.
Not assessed is not a pass. The row explains why no result was available.
After the result
Each finding includes what to change and, where possible, a command to verify the fix.
If the setting cannot be changed at the layer you control, the finding points to the layer that needs to be updated instead.
If your organisation falls under the Website Security Standard B.E. 2568 (2025), this check does not map findings to the clauses in that standard.
Use the self-assessment for that standard instead.
Frequently asked questions
Can I check a site I do not own?
Yes. The site operator may see our scanner in their logs. We record who started the check and keep that record for 90 days, as described in our privacy policy. The form asks you to confirm that the site will be contacted externally.
Why does a repeated check return the same result?
Results are cached for 300 seconds per domain. Checks made during that period return the same report. The page shows that the result is cached and how long remains before you can run a fresh check. The cache cannot be bypassed.
Which port is checked?
Port 443. If you include another port in the domain, it is ignored. Port 80 is contacted only to check whether HTTP redirects to HTTPS.
What does PQC Readiness check?
The key exchange actually negotiated with the server, not the groups it advertises. A hybrid group such as X25519MLKEM768, or a pure ML-KEM group, passes. Certificate signatures are checked by the SSL/TLS module instead.
The result says the key exchange is classical only. How urgent is that?
It is not an emergency, but it is worth including in your next TLS library upgrade. Use a TLS implementation that supports ML-KEM and enable a hybrid group. If the site is behind a CDN, configure it there because TLS terminates at the CDN. Keep a classical group available for clients that do not support PQC yet, and test compatibility before rollout.
Does this replace a penetration test?
No. This check only looks at what the server exposes without authentication. Issues such as broken access control, business-logic flaws, and injection need deeper testing and are part of a penetration test.
