example.comReport

About score impact

• Remove what is being served, and close the way in

  Engine output (verbatim)

  no malware-feed key is configured, so the feed could not be asked

  Score gain: not computed

  Reason: This item could not be inspected from publicly available information.

  Subjects (1 in total, including any that were not inspected)

  • example.com (not inspected)

  Risk detail

  A host recorded as distributing malware is serving files that are actually being handed out. Almost always an intruder put them there, and the server is being used as a tool against other people. The victims are third parties; the responsibility sits with the host serving it.

  Remediation steps

  1. Do not start by deleting the files.
  2. Establish first, from the access logs and the files' timestamps, when and by what route they arrived — deleting alone means the same route puts them back.
  3. Close that route, confirm nothing else was planted (a web shell, a cron entry, an altered configuration), and only then remove them.
  4. Afterwards request removal from the feed.
  Related terms

  • brute-force attack - Trying password or credential combinations one after another until one happens to work.
  • private key - A value meant to be known only to its holder, used to prove identity or decrypt data. Anyone who obtains a copy can act as the holder.
  View evidence (1 in total)

  • threatsubject example.comcollected 01/09/2026 09:00 GMT+9

    safe_browsing_asked

    false

    malware_feed_asked

    false

    unconfigured

    safe_browsing - malware_feed

    evidence id threat:threat.intel:example.com

• Remove the cause, then request a review

  Engine output (verbatim)

  no threat-intelligence key is configured, so the service could not be asked

  Score gain: not computed

  Reason: This item could not be inspected from publicly available information.

  Subjects (1 in total, including any that were not inspected)

  • example.com (not inspected)

  Risk detail

  A listing in Google Safe Browsing puts a red interstitial in front of the site in Chrome, Safari and Firefox alike. Visitors never reach the page. It also drops out of search results and cannot be advertised. The usual causes are a compromised page planting redirects, or malicious content posted through a user-submission feature.

  Remediation steps

  1. Register the site in Google Search Console and read the affected pages under Security Issues.
  2. Fixing only the pages named brings it straight back.
  3. Close the way in first — an outdated plugin, stolen administrator credentials, a writable upload directory — then request a review from Search Console.
  4. The review takes a few days.
  Related terms

  • phishing - A scam message impersonating someone trusted, aiming to trick the reader into typing a password or other secret themselves.
  • subdomain takeover - Registering an outside service that a subdomain still points to after it was abandoned, so the attacker now controls what that subdomain serves.
  View evidence (1 in total)

  • threatsubject example.comcollected 01/09/2026 09:00 GMT+9

    safe_browsing_asked

    false

    malware_feed_asked

    false

    unconfigured

    safe_browsing - malware_feed

    evidence id threat:threat.intel:example.com

About score impact

example.com in these instructions is a placeholder — read it as your own domain. It is not substituted automatically, because the same text also names real third-party hosts such as letsencrypt.org.

• Strip metadata before publishing

  Engine output (verbatim)

  the page links to no document on this site

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (not applicable)

  Risk detail

  PDF and Office files embed the author's name, who last saved them, the software and version used, and the path the file was saved from. That path carries internal file-server names and account names as they are. To an attacker it is a named individual to target and a sketch of the internal layout.

  Remediation steps

  1. This is a warning; some documents carry an author line deliberately.
  2. What to check is whether anything unintended is in there.
  3. Word and Excel remove personal and hidden data in one pass under File, Info, Inspect Document.
  4. For PDFs, use Acrobat's Redact then Sanitize Document, or exiftool -all= file.pdf.
  5. Build the step into your publishing procedure, and work through what is already published.
  Related terms

  • phishing - A scam message impersonating someone trusted, aiming to trick the reader into typing a password or other secret themselves.
  • banner - A reply a server sends to whoever connects to it, revealing the name and version of the software it runs.
  View evidence (0 in total)

  This item cites no evidence id.

• Rotate the credentials, then purge them from the history

  Engine output (verbatim)

  the site links to no public code repository

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (not applicable)

  Risk detail

  A configuration file committed to a public repository hands its credentials to anyone. Making the repository private, or rewriting the history, does not invalidate what has already been taken. Automated harvesting of public repositories runs continuously, and the gap between publication and use is minutes.

  Remediation steps

  1. Rotate the credentials and revoke the old ones first; removing them from the repository comes second.
  2. Then purge them from the history with git filter-repo, force-push, and ask collaborators to re-clone.
  3. To stop it recurring, add the configuration files to .gitignore and run a pre-commit scanner (gitleaks, git-secrets).
  4. Supply the values from environment variables or a secret manager instead.
  Related terms

  • private key - A value meant to be known only to its holder, used to prove identity or decrypt data. Anyone who obtains a copy can act as the holder.
  View evidence (0 in total)

  This item cites no evidence id.

• Correct the BIMI record's syntax

  Engine output (verbatim)

  no BIMI record published; BIMI is optional

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (not applicable)

  Risk detail

  BIMI puts your logo beside your messages in the recipient's mailbox, which makes a genuine sender visible as one. A record with the wrong syntax simply does not display, leaving your mail looking like anyone else's — including an impersonator's.

  Remediation steps

  1. Publish a TXT record at default._bimi of the form v=BIMI1; l=https://example.com/logo.svg;.
  2. The l= tag needs an HTTPS URL for the logo, and the logo must be SVG Tiny Portable/Secure — an ordinary SVG will not render.
  3. Major receivers additionally require a Verified Mark Certificate and DMARC at p=quarantine or stricter.
  4. Check with dig +short TXT default._bimi.example.com.
  Related terms

  • DMARC - A published instruction telling receivers what to do with mail that fails the sender checks: deliver it, flag it, or drop it.
  • phishing - A scam message impersonating someone trusted, aiming to trick the reader into typing a password or other secret themselves.
  View evidence (0 in total)

  This item cites no evidence id.

• Publish the authorisation record at the destination domain

  Engine output (verbatim)

  no report address outside this domain

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (not applicable)

  Risk detail

  Sending DMARC aggregate reports to an address outside your own domain requires the receiving domain to publish an authorisation record (RFC 7489 §7.1). Without it, conforming receivers send nothing. It shows up as a perfectly correct report address that never receives a single report.

  Remediation steps

  1. If you use a report-analysis service, publish the authorisation record they specify: a TXT record at example.com._report._dmarc.<their domain> containing v=DMARC1.
  2. The provider often sets this up themselves, so ask them first.
  3. If you send to another domain of your own, add the same record there.
  4. Confirm with dig +short TXT example.com._report._dmarc.<their domain> returning v=DMARC1.
  Related terms

  • DMARC - A published instruction telling receivers what to do with mail that fails the sender checks: deliver it, flag it, or drop it.
  • aggregate report - A periodic summary that receivers send back describing who has been sending mail claiming to be from a given domain.
  View evidence (0 in total)

  This item cites no evidence id.

• Remove unsafe-eval and bare unsafe-inline

  Engine output (verbatim)

  no Content-Security-Policy to assess

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (not applicable)

  Risk detail

  `unsafe-inline` permits scripts written into the page — the very thing CSP exists to stop. `unsafe-eval` leaves the string-to-code path open. A policy carrying either is a header that exists without stopping an injected script.

  Remediation steps

  1. Give inline scripts a nonce: generate a random value per response, put it in the policy as script-src 'nonce-<value>', and repeat it as <script nonce="<value>">.
  2. Once a nonce or hash is present, browsers that understand it ignore unsafe-inline entirely, so keeping it for older browsers costs nothing.
  3. For unsafe-eval, find and replace the library that calls eval or new Function.
  4. Confirm with curl -sI https://example.com | grep -i content-security-policy and a browser console free of violation reports.
  Related terms

  • CSP - A declared list of the scripts allowed to run and the outside locations allowed to be loaded on a page.
  • XSS - An attack where a third party sneaks a script into a page that was not meant to contain one, and it runs in a visitor's browser.
  • nonce - A value generated fresh each time and trusted only once, used as a one-time proof that something belongs to the current page.
  View evidence (0 in total)

  This item cites no evidence id.

About score impact

example.com in these instructions is a placeholder — read it as your own domain. It is not substituted automatically, because the same text also names real third-party hosts such as letsencrypt.org.

• Issued certificates are accounted for

  Engine output (verbatim)

  1 certificates in the public logs, covering 2 names from 1 issuers

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Every certificate issued for your domain is published to the certificate transparency logs — which means an issuance you did not ask for appears there too. A name or an issuer you do not recognise means either the DNS was taken over, or someone inside obtained a certificate through a route nobody is tracking.

  Remediation steps

  1. This item reports an observation and deducts nothing.
  2. Read the names and issuers and confirm you recognise them.
  3. For an issuance you cannot account for, ask that CA to revoke it and review who holds the DNS and registrar credentials.
  4. For ongoing watching, restrict which authorities may issue with a CAA record (dns.caa) and subscribe to a transparency-log notification service.
  Related terms

  • CT log - A public, tamper-evident record of every certificate issued, so a forged certificate leaves a trace anyone can check.
  • Certificate Authority - A company that verifies a server's identity and then issues it a certificate.
  • CAA record - A DNS record naming which companies are allowed to issue certificates for a domain.
  • SAN - A field in a certificate listing every domain name it covers, so one certificate can serve several names.
  View evidence (1 in total)

  • CT logs (crt.sh + Cert Spotter)subject example.comcollected 01/09/2026 09:00 GMT+9

    certificates

    1

    example.com, www.example.com

    C=US, O=Let's Encrypt, CN=R11 · 2099-01-01 → 2099-04-01

    evidence id crtsh:crtsh.certs:example.com

• Visually confusable domains are known

  Engine output (verbatim)

  none of the 15 variants checked is registered

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Accented Latin letters, and the digit zero against the letter o, render close enough to be indistinguishable on screen. A domain with one such substitution survives a visitor reading the URL carefully. Unlike a mistyped name, nothing about this is the visitor's fault.

  Remediation steps

  1. This item reports an observation too.
  2. Establish who owns each name listed and what is actually served there.
  3. Where content impersonates you, report it to that registrar's abuse contact and, where appropriate, to a national CERT.
  4. For your own users, keeping the URLs in your mail in a consistent form, with link text matching the destination, is what gives them something to compare against.
  Related terms

  • phishing - A scam message impersonating someone trusted, aiming to trick the reader into typing a password or other secret themselves.
  View evidence (1 in total)

  • dns-repsubject example.comcollected 01/09/2026 09:00 GMT+9

    typos_tried

    42

    homoglyphs_tried

    15

    evidence id dns-rep:dns.lookalike:example.com

• Look-alike domains are known

  Engine output (verbatim)

  none of the 42 variants checked is registered

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A domain one character away is where a visitor in a hurry actually lands. A convincing sign-in page there collects credentials directly, and the same names appear as the sender of invoice fraud aimed at your customers. This item is not a defect in your domain; it reports what is around it.

  Remediation steps

  1. A registered look-alike is not necessarily an attack.
  2. It may be a different business with a similar name, or a defensive registration you made yourself.
  3. Establish who owns each one first.
  4. Where a name genuinely carries content impersonating you, report it to that registrar's abuse contact.
  5. For the handful of spellings visitors most plausibly mistype, registering them yourself and redirecting to the real domain is worth the fee.
  Related terms

  • phishing - A scam message impersonating someone trusted, aiming to trick the reader into typing a password or other secret themselves.
  View evidence (1 in total)

  • dns-repsubject example.comcollected 01/09/2026 09:00 GMT+9

    typos_tried

    42

    homoglyphs_tried

    15

    evidence id dns-rep:dns.lookalike:example.com

• The certificate chain is complete

  Engine output (verbatim)

  the certificates the server sends link up without a gap

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A server has to hand over enough intermediate certificates during the handshake for the client to reach a trusted root. When it does not, browsers that happen to hold that intermediate succeed and everything else fails. It does not reproduce on the developer's machine — it shows up as some visitors, some older devices, and a partner's integration failing.

  Remediation steps

  1. Serve the CA's intermediate concatenated with your own certificate, server certificate first.
  2. In nginx that is what ssl_certificate should point at — with Let's Encrypt, fullchain.pem, not cert.pem.
  3. In Apache, use SSLCertificateChainFile or an SSLCertificateFile assembled the same way.
  4. Confirm that openssl s_client -connect example.com:443 -showcerts </dev/null lists the intermediate after the server certificate.
  Related terms

  • Certificate Authority - A company that verifies a server's identity and then issues it a certificate.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• A currently valid certificate exists for apex or www

  Engine output (verbatim)

  1 valid certificates in CT logs

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  This verdict comes from the public CT indexes (crt.sh and Cert Spotter, merged). Under load an index answers with an empty list, and then the fact is not "no certificate" but "the index did not answer" (on 2026-09-08 a real, valid certificate went unfound this way). Only entries present with none valid is a failure; an empty index is reported as needing confirmation. With no valid certificate for the name people actually type, the browser interstitial becomes routine and users learn to click through it. An on-path attacker's forged certificate — or a plain-HTTP downgrade — then reads as the same familiar warning and gets accepted.

  Remediation steps

  1. Confirm on the host first: openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -ext subjectAltName.
  2. If it is unexpired and the SAN list covers apex and www, this item is the index's miss — evaluate again later.
  3. If not, continue.
  4. Issue one certificate whose SAN list covers both the apex and www: certbot --nginx -d example.com -d www.example.com, or add both names to the request at a commercial CA.
  5. Install it and reload the server (nginx -t && systemctl reload nginx).
  6. Confirm with openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -ext subjectAltName showing both names and a future notAfter.
  7. This check reads CT logs, so allow time for the new certificate to appear on crt.sh.
  Related terms

  • Certificate Authority - A company that verifies a server's identity and then issues it a certificate.
  • SAN - A field in a certificate listing every domain name it covers, so one certificate can serve several names.
  • apex domain - A domain name written on its own, with no leading label such as www.
  • CT log - A public, tamper-evident record of every certificate issued, so a forged certificate leaves a trace anyone can check.
  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  View evidence (1 in total)

  • CT logs (crt.sh + Cert Spotter)subject example.comcollected 01/09/2026 09:00 GMT+9

    certificates

    1

    example.com, www.example.com

    C=US, O=Let's Encrypt, CN=R11 · 2099-01-01 → 2099-04-01

    evidence id crtsh:crtsh.certs:example.com

• Newest certificate is not about to expire

  Engine output (verbatim)

  newest certificate valid for 26510 more days

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  An expired certificate makes every browser and API client refuse the connection, and the usual emergency response — turning certificate verification off at the client — hands an on-path attacker exactly the position they want. Renewal you have to remember is renewal that eventually gets missed.

  Remediation steps

  1. Automate renewal instead of diarising it.
  2. With certbot, check the timer runs (systemctl list-timers | grep certbot) and prove the path with certbot renew --dry-run; with acme.sh, confirm acme.sh --cron --home ~/.acme.sh is in cron.
  3. Reload the server from a deploy hook (--deploy-hook "systemctl reload nginx").
  4. This check warns at 14 days or fewer remaining, so confirm after a renewal that openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate sits well clear of that mark — automated renewal of a 90-day certificate normally leaves 30 days or more.
  Related terms

  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  View evidence (1 in total)

  • CT logs (crt.sh + Cert Spotter)subject example.comcollected 01/09/2026 09:00 GMT+9

    certificates

    1

    example.com, www.example.com

    C=US, O=Let's Encrypt, CN=R11 · 2099-01-01 → 2099-04-01

    evidence id crtsh:crtsh.certs:example.com

• The certificate covers this host name

  Engine output (verbatim)

  the certificate covers this host name

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  When the names in the certificate do not include the host being connected to, the browser stops on a warning page. The visitor either turns back or learns to click through warnings. Once that habit sets in, the warning for a real interception attempt gets the same click.

  Remediation steps

  1. Reissue with every host name you actually publish listed in the certificate's subjectAltName.
  2. If you serve both apex and www, both belong there.
  3. Read what is there now with openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'.
  4. With Let's Encrypt, request them together: certbot certonly -d example.com -d www.example.com.
  5. If several virtual hosts share the address, confirm SNI selects the certificate you meant.
  Related terms

  • SAN - A field in a certificate listing every domain name it covers, so one certificate can serve several names.
  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  • apex domain - A domain name written on its own, with no leading label such as www.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• The certificate key is long enough

  Engine output (verbatim)

  ECDSA key of 256 bits

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  The shorter the key, the more feasible it becomes to compute the private half. Whoever recovers it can impersonate the name in perfectly ordinary-looking traffic. RSA at 1024 bits is already in practical reach, and public CAs will not issue below 2048.

  Remediation steps

  1. Generate a new key — RSA at 2048 bits or more, or an elliptic curve at P-256 or better — and reissue.
  2. Use openssl genrsa -out key.pem 2048, or openssl ecparam -genkey -name prime256v1 -out key.pem for a curve, which is also cheaper per handshake.
  3. With Let's Encrypt, certbot certonly --key-type ecdsa -d example.com produces a curve key.
  4. A new key means a new certificate, so arrange it in advance with anyone pinning the current fingerprint.
  Related terms

  • private key - A value meant to be known only to its holder, used to prove identity or decrypt data. Anyone who obtains a copy can act as the holder.
  • key pinning - Fixing in advance which single key will be trusted as genuine, rather than trusting any key that shows up.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• The certificate is not revoked

  Engine output (verbatim)

  the stapled status says the certificate is not revoked

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A revoked certificate was withdrawn because the private key leaked, or it was mis-issued, or one of those was suspected. Continuing to serve with a withdrawn key means anyone holding that key can impersonate you. Browsers commonly skip revocation checking when the check itself fails, so visitors see nothing.

  Remediation steps

  1. Issue and install a replacement now.
  2. Do not reissue with the same key — if a key leak was the reason, start by generating a new one.
  3. Afterwards check the other services that used that key: mail, VPN, APIs.
  4. Confirm against the CA's published CRL or the OCSP status stapled to a TLS connection.
  Related terms

  • revocation - Declaring an already-issued certificate invalid before its stated expiry. Nothing guarantees that everyone receiving it will check that declaration.
  • private key - A value meant to be known only to its holder, used to prove identity or decrypt data. Anyone who obtains a copy can act as the holder.
  • Certificate Authority - A company that verifies a server's identity and then issues it a certificate.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• Issued by a certificate authority

  Engine output (verbatim)

  the certificate is issued by a separate authority

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A self-signed certificate is only its own word that it is correct — nothing outside it vouches for it. The browser warns, and visitors learn to proceed anyway. From then on, an attacker substituting a different self-signed certificate looks exactly the same to them.

  Remediation steps

  1. Replace it with a certificate from a public CA.
  2. With Let's Encrypt, certbot --nginx -d example.com or certbot --apache -d example.com obtains and installs one.
  3. Issuance proves you control the domain, so either port 80 or DNS must be usable.
  4. Afterwards confirm issuer and subject differ: openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject.
  5. Even for an internal-only host, run your own CA and distribute its root to the devices rather than staying on a self-signed certificate.
  Related terms

  • Certificate Authority - A company that verifies a server's identity and then issues it a certificate.
  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• No internal host names in public certificates

  Engine output (verbatim)

  no internal-looking host names in the public certificates

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Every certificate is published to the certificate transparency logs when it is issued, and anyone can search them. Putting `staging.example.com` or `jenkins.example.com` in a public certificate hands out the shape of the internal estate as a list. To an attacker that is a map for choosing where to try.

  Remediation steps

  1. Issue certificates for internal hosts from an internal CA rather than a public one.
  2. Where a public certificate is needed, a single wildcard keeps the individual names out of the logs.
  3. Names already published cannot be withdrawn, so confirm with the firewall that those hosts are unreachable from outside and operate them as known.
  4. See the current state at https://crt.sh/?q=%25.example.com.
  Related terms

  • CT log - A public, tamper-evident record of every certificate issued, so a forged certificate leaves a trace anyone can check.
  • SAN - A field in a certificate listing every domain name it covers, so one certificate can serve several names.
  • wildcard certificate - A single certificate that covers every subdomain under one name at once, such as *.example.com.
  • Certificate Authority - A company that verifies a server's identity and then issues it a certificate.
  View evidence (1 in total)

  • CT logs (crt.sh + Cert Spotter)subject example.comcollected 01/09/2026 09:00 GMT+9

    certificates

    1

    example.com, www.example.com

    C=US, O=Let's Encrypt, CN=R11 · 2099-01-01 → 2099-04-01

    evidence id crtsh:crtsh.certs:example.com

• Signed with a strong algorithm

  Engine output (verbatim)

  signed with SHA256-RSA

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  SHA-1 and MD5 have demonstrated collisions: two different contents that carry the same signature value. An attacker who can produce a second certificate the same signature accepts has stepped around the CA's guarantee entirely. Major browsers already refuse these signatures.

  Remediation steps

  1. Reissue with SHA-256 or better.
  2. Public CAs default to SHA-256 today, so simply obtaining a fresh certificate usually settles it.
  3. Check with openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep 'Signature Algorithm'.
  4. If an internal CA issued it, review that CA's default signing algorithm as well.
  Related terms

  • Certificate Authority - A company that verifies a server's identity and then issues it a certificate.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• The chain reaches a trusted root

  Engine output (verbatim)

  the chain reaches a trusted root

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  If the chain does not reach a root the browser trusts, verification fails even when the certificate itself is perfectly legitimate. A missing intermediate is the usual cause. It shows up as "works in my browser, warns on some devices", which is exactly the shape of problem that goes unnoticed.

  Remediation steps

  1. Concatenate the CA's intermediate certificate with your own, server certificate first.
  2. In nginx, point ssl_certificate at that combined file — with Let's Encrypt that is fullchain.pem, not cert.pem.
  3. In Apache, use SSLCertificateChainFile, or an SSLCertificateFile assembled the same way.
  4. Then confirm the tail of openssl s_client -connect example.com:443 -servername example.com </dev/null reads Verify return code: 0 (ok).
  Related terms

  • Certificate Authority - A company that verifies a server's identity and then issues it a certificate.
  • revocation - Declaring an already-issued certificate invalid before its stated expiry. Nothing guarantees that everyone receiving it will check that declaration.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• Zone transfer is refused

  Engine output (verbatim)

  all 2 name servers refuse a zone transfer

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A name server that transfers the zone to anyone hands over every record in one request — host names you never published, development environments, the names of internal systems, as a list. The attacker no longer has to guess what exists where.

  Remediation steps

  1. Restrict it to the secondary name servers' addresses.
  2. In BIND, allow-transfer { 203.0.113.53; }; on the zone or in options, with TSIG key authentication as well where you can.
  3. In PowerDNS, allow-axfr-ips.
  4. Hosted DNS services refuse by default, but check the setting if you run a secondary alongside.
  5. Confirm with dig AXFR example.com @ns1.example.com returning Transfer failed.
  Related terms

  • zone transfer - Copying a domain's full set of records from one authoritative server to another.
  • authoritative name server - A server that holds the official answers for a domain and responds to lookups from everyone else.
  View evidence (1 in total)

  • dns-authsubject example.comcollected 01/09/2026 09:00 GMT+9

    child_ns

    ns1.example.net - ns2.example.net

    evidence id dns-auth:dns.authority:example.com

• The delegation matches the zone

  Engine output (verbatim)

  the delegation matches the zone's NS records

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  When the name servers registered at the registrar differ from the NS records the zone itself publishes, queries reach different servers depending on the path. If the stale side still answers, it keeps returning pre-update content; if it has stopped, queries that land there fail. Either way it presents as "sometimes it does not work", which is hard to trace.

  Remediation steps

  1. Compare the name server list in the registrar's control panel with the zone's NS records and make them match.
  2. Decide which is authoritative and bring the other into line.
  3. The two most commonly diverge just after a zone move or a change of DNS provider.
  4. Confirm that dig +short NS example.com agrees with dig +norecurse NS example.com @<a parent name server>.
  Related terms

  • delegation - The parent domain's declaration of which servers are responsible for answering on behalf of a name below it.
  • authoritative name server - A server that holds the official answers for a domain and responds to lookups from everyone else.
  View evidence (1 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

• Name servers span more than one network

  Engine output (verbatim)

  name servers span 2 networks

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Name servers packed into one network all stop answering together when that network fails or is attacked. Once the name cannot be resolved, neither the website nor the mail is reachable. Adding more servers in the same place is not redundancy.

  Remediation steps

  1. Put at least one on a different provider and a different network.
  2. Running two DNS hosting services is the quickest route: set both providers' name servers at the registrar.
  3. Keep the zone contents in sync between them and agree a procedure so one is never updated alone.
  4. Then resolve each host from dig +short NS example.com and confirm the addresses sit in different networks.
  Related terms

  • authoritative name server - A server that holds the official answers for a domain and responds to lookups from everyone else.
  • delegation - The parent domain's declaration of which servers are responsible for answering on behalf of a name below it.
  View evidence (1 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

• At least two authoritative name servers

  Engine output (verbatim)

  2 name servers

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A single authoritative server is one outage away from the whole domain being unresolvable, and one compromise away from an attacker answering for every name you own — A, MX, and the ACME challenge used to issue certificates for you.

  Remediation steps

  1. Add at least one more authoritative server on separate infrastructure: a second DNS provider, or a secondary zone (BIND: also-notify/allow-transfer on the primary, type secondary; on the other).
  2. Then register the full NS set at the registrar — the parent delegation is what resolvers follow, and it does not update itself.
  3. Confirm that the final delegation in dig +trace NS example.com — the NS set returned by the parent TLD's own servers — lists them all, and that dig SOA example.com @<ns> returns the same serial from each.
  Related terms

  • authoritative name server - A server that holds the official answers for a domain and responds to lookups from everyone else.
  • delegation - The parent domain's declaration of which servers are responsible for answering on behalf of a name below it.
  • zone transfer - Copying a domain's full set of records from one authoritative server to another.
  • SOA record - A DNS record carrying a zone's administrative details and a serial number that increases every time its contents change.
  • ACME challenge - An exchange used by automated certificate issuance to confirm that the requester genuinely controls the domain.
  View evidence (1 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

• Name servers do not resolve for strangers

  Engine output (verbatim)

  none of the 2 name servers resolves for strangers

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  An authoritative name server that answers recursive queries from anyone becomes an amplifier for DNS reflection attacks: a small query producing a large answer, aimed at a third party whose address was forged as the source. The victim is someone else, but the traffic is recorded as coming from your server.

  Remediation steps

  1. Disable recursion on authoritative servers.
  2. In BIND's options, recursion no; and allow-recursion { none; };.
  3. PowerDNS separates the authoritative and recursive products, so the authoritative side has no recursion to turn off.
  4. Where an internal resolver is needed, run it as a separate server that accepts queries only from inside.
  5. Confirm with dig @ns1.example.com example.org returning REFUSED.
  Related terms

  • authoritative name server - A server that holds the official answers for a domain and responds to lookups from everyone else.
  • brute-force attack - Trying password or credential combinations one after another until one happens to work.
  View evidence (1 in total)

  • dns-authsubject example.comcollected 01/09/2026 09:00 GMT+9

    child_ns

    ns1.example.net - ns2.example.net

    evidence id dns-auth:dns.authority:example.com

• SOA timers are sensible

  Engine output (verbatim)

  SOA timers are within the usual range

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  The SOA timers set how often a secondary name server refetches the zone, and how long it keeps answering when it cannot. Too short an expire and a brief outage at the primary erases the whole zone. A retry longer than the refresh means the retry after a failure is slower than the ordinary update, which is backwards.

  Remediation steps

  1. Keep refresh between 20 minutes and 24 hours; retry between 2 minutes and 2 hours and shorter than refresh; expire between 2 and 8 weeks; minimum between 5 minutes and 24 hours.
  2. Edit the SOA line in the zone file, bump the serial, and reload.
  3. On a hosted DNS service these are fields in the control panel.
  4. Confirm with the last four numbers of dig +short SOA example.com.
  Related terms

  • SOA record - A DNS record carrying a zone's administrative details and a serial number that increases every time its contents change.
  • authoritative name server - A server that holds the official answers for a domain and responds to lookups from everyone else.
  View evidence (1 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

• Subdomains point at names that exist

  Engine output (verbatim)

  none of the 1 subdomains points at a claimable name

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Leaving a CNAME to a service you have cancelled means whoever registers that name next serves whatever they like on your subdomain. They can obtain a certificate for it too, so a fake page runs on your genuine domain behind a padlock. Neither the visitor nor the browser can tell.

  Remediation steps

  1. Remove the CNAME whose target has gone.
  2. The order matters: delete the DNS record before cancelling the external service.
  3. The other way round leaves the name unclaimed in between.
  4. If it is already unclaimed, delete the record now and check https://crt.sh/?q=<the subdomain> for certificates issued in the meantime.
  5. Confirm that dig +short <the subdomain> returns nothing.
  Related terms

  • subdomain takeover - Registering an outside service that a subdomain still points to after it was abandoned, so the attacker now controls what that subdomain serves.
  • CT log - A public, tamper-evident record of every certificate issued, so a forged certificate leaves a trace anyone can check.
  • phishing - A scam message impersonating someone trusted, aiming to trick the reader into typing a password or other secret themselves.
  View evidence (1 in total)

  • DNS answersubject api.example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.2

    evidence id dns-sub:dns.host:api.example.com

• Wildcard DNS is under control

  Engine output (verbatim)

  an unregistered name does not resolve

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A zone with a wildcard answers names that do not exist. A mistyped name opens something plausible, so the visitor never learns they got it wrong. For an attacker it is a foothold: take a certificate for any name and stand up a convincing page on your domain.

  Remediation steps

  1. Delete the * record and define the host names you actually serve.
  2. If the wildcard is deliberate — per-customer subdomains assigned on the fly, say — write that into the operating procedure alongside how the wildcard certificate is managed and what happens to requests for unused names.
  3. Confirm by resolving a random name, dig +short random-name-check.example.com, and getting nothing back.
  Related terms

  • subdomain takeover - Registering an outside service that a subdomain still points to after it was abandoned, so the attacker now controls what that subdomain serves.
  • wildcard certificate - A single certificate that covers every subdomain under one name at once, such as *.example.com.
  View evidence (1 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

• The registration has runway

  Engine output (verbatim)

  the registration runs for another 26644 days

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  When a registration lapses, the website and the mail stop together. After a further grace period the domain becomes available to anyone, and certificates issued for it and mail received at it are then done in your name. Expiry is not a misconfiguration; it is a renewal someone forgot.

  Remediation steps

  1. Turn auto-renewal on at the registrar, and check the expiry date of the card the registration is billed to.
  2. The contact address matters just as much: renewal notices go there and nowhere else.
  3. Make it a shared team address rather than one person's. Add the date to your own monitoring with alerts at 60 and 30 days.
  4. Confirm with the Expiry Date in whois example.com.
  Related terms

  • subdomain takeover - Registering an outside service that a subdomain still points to after it was abandoned, so the attacker now controls what that subdomain serves.
  • phishing - A scam message impersonating someone trusted, aiming to trick the reader into typing a password or other secret themselves.
  View evidence (1 in total)

  • rdapsubject example.comcollected 01/09/2026 09:00 GMT+9

    found

    true

    service_available

    true

    expiration

    2099-08-13T00:00:00Z

    registration

    0001-01-01T00:00:00Z

    last_changed

    0001-01-01T00:00:00Z

    statuses

    clienttransferprohibited - clientdeleteprohibited

    registrar

    Example Registrar, Inc.

    evidence id rdap:rdap.domain:example.com

• Registrar locks are set

  Engine output (verbatim)

  the registration carries the transfer and delete locks

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Without a transfer lock, whoever gets into the registrar account can move the domain to another registrar outright. Once the transfer completes, getting it back is extremely hard. Losing the domain means losing the website, the mail, and every certificate issued for the name.

  Remediation steps

  1. Enable the transfer lock (clientTransferProhibited) and the delete lock (clientDeleteProhibited) in the registrar's control panel.
  2. Most registrars set them by default, but they are commonly left off after a past transfer.
  3. Put multi-factor authentication on the registrar account as well.
  4. The locks do not protect the account; they limit what an intruder can do once inside it.
  5. Confirm with the Domain Status in whois example.com.
  Related terms

  • multi-factor authentication - Confirming someone's identity with more than a password alone, such as a code sent to a device they hold.
  View evidence (1 in total)

  • rdapsubject example.comcollected 01/09/2026 09:00 GMT+9

    found

    true

    service_available

    true

    expiration

    2099-08-13T00:00:00Z

    registration

    0001-01-01T00:00:00Z

    last_changed

    0001-01-01T00:00:00Z

    statuses

    clienttransferprohibited - clientdeleteprohibited

    registrar

    Example Registrar, Inc.

    evidence id rdap:rdap.domain:example.com

• Published API specifications are intentional

  Engine output (verbatim)

  no API specification is served at the checked paths

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  An OpenAPI definition or a specification browser is a complete list of the operations available, their arguments and the shape of internal identifiers. Publishing one is often deliberate — but internal APIs and administrative operations frequently end up in the same definition. For an attacker it removes the work of enumerating what to try.

  Remediation steps

  1. This is a warning; publishing an API specification is a legitimate thing to do.
  2. What to check is whether the definition also covers internal or administrative operations.
  3. If it does, split the public and internal definitions, or put the specification browser behind authentication.
  4. For the operations that require authentication, confirm the authorisation actually holds.
  5. A published specification is not the vulnerability; authorisation not matching it is.
  View evidence (1 in total)

  • httpsubject example.comcollected 01/09/2026 09:00 GMT+9

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    evidence id http:http.probes:example.com

• Service versions are not published in banners

  Engine output (verbatim)

  no issues across indexed hosts

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  The public index holds a version-qualified CPE for this host, which is only possible because the host named its own version. An attacker reads it and narrows straight to the known vulnerabilities for that release. This bites whether or not the build is actually patched: the index matches CVEs against the version it was told, so a patched host stays on every "vulnerable nginx" list built from it — and those lists are used as target lists.

  Remediation steps

  1. For nginx, add server_tokens off; to the http block and run nginx -t && systemctl reload nginx.
  2. For Apache, ServerTokens Prod and ServerSignature Off.
  3. For Postfix, smtpd_banner = $myhostname ESMTP.
  4. Drop application headers such as X-Powered-By.
  5. Confirm with curl -sI https://example.com | grep -i '^server:' showing no version.
  6. Hiding the version is not itself a defence and is no substitute for updating, and the public index will keep its old value until its next scan.
  Related terms

  • banner - A reply a server sends to whoever connects to it, revealing the name and version of the software it runs.
  • CVE - A shared reference number assigned to a specific publicly known software flaw.
  View evidence (0 in total)

  This item cites no evidence id.

• Cross-domain policy is controlled

  Engine output (verbatim)

  no cross-domain policy file is served

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  `crossdomain.xml` configured Flash and Silverlight, both of which are gone. With `domain="*"` it let any site make credentialed requests against this domain in the implementations that read it. Browsers no longer do — but the file still being there means a policy from that era was never revisited.

  Remediation steps

  1. If nothing you run uses Flash or Silverlight, delete crossdomain.xml and clientaccesspolicy.xml.
  2. Where that is not possible, replace domain="*" with the specific domains.
  3. Cross-origin control today is CORS (web.cors).
  4. Confirm with curl -sI https://example.com/crossdomain.xml returning 404.
  View evidence (1 in total)

  • httpsubject example.comcollected 01/09/2026 09:00 GMT+9

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    evidence id http:http.probes:example.com

• No database ports exposed

  Engine output (verbatim)

  no issues across indexed hosts

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Redis, Memcached, Elasticsearch and MongoDB ship with no authentication: once reachable from the internet, anyone can read and write their contents. MySQL, PostgreSQL and SQL Server do authenticate, but exposed they are the first thing internet-wide scanners try credentials against. All of them were designed for a trusted network.

  Remediation steps

  1. Bind each database to a private address: bind-address = 127.0.0.1 in MySQL's mysqld.cnf, listen_addresses = 'localhost' in postgresql.conf, bind 127.0.0.1 plus protected-mode yes in redis.conf, network.host: 127.0.0.1 in elasticsearch.yml, net.bindIp: 127.0.0.1 in mongod.conf.
  2. Where the application runs on another host, restrict the port to that subnet in the firewall or security group instead.
  3. After restarting, confirm from outside that nmap -Pn -p 1433,3306,5432,6379,9200,11211,27017 <ip> reports nothing open, and from the application host that it still connects.
  Related terms

  • brute-force attack - Trying password or credential combinations one after another until one happens to work.
  View evidence (0 in total)

  This item cites no evidence id.

• No stock default page is left serving

  Engine output (verbatim)

  the response is a configured site, not a stock page

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A server software's welcome page means nobody configured anything for that name. A forgotten virtual host stays on an old version because it is outside whatever gets updated. To an attacker it marks an entrance nobody is watching.

  Remediation steps

  1. If the name is not going to be used, remove its DNS record.
  2. On the server, arrange that a request with an unexpected Host header does not reach a default virtual host: in nginx, a default server with server_name _; and return 444;, and in Apache, the same treatment for the first VirtualHost.
  3. Confirm that curl -sI https://example.com/ returns what you intended.
  Related terms

  • banner - A reply a server sends to whoever connects to it, revealing the name and version of the software it runs.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    HTTP status

    200

    final URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    evidence id http:http.headers:example.com

• No developer or operations UIs exposed

  Engine output (verbatim)

  no issues across indexed hosts

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A Jenkins, GitLab, Grafana or Kibana console on the open internet is reconnaissance material by itself. Many allow anonymous viewing out of the box, and some — Jenkins above all — lead from running a job to running commands on the host. This check reads the product fingerprint a public index recorded, so moving the service off its default port does not hide it.

  Remediation steps

  1. Move the console somewhere the internet cannot reach directly: behind a VPN or bastion, or behind a reverse proxy that authenticates first, with the source addresses restricted.
  2. Changing the port number is not a fix — the index recognises the product, not the port.
  3. Turn off anonymous access in the product as well (in Jenkins, remove Anonymous permissions under Configure Global Security; in Grafana, [auth.anonymous] enabled = false in grafana.ini).
  4. The public index will keep showing the old result until it rescans.
  View evidence (0 in total)

  This item cites no evidence id.

• Directory listing is off

  Engine output (verbatim)

  none of the checked directories lists its contents

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  With listings on, a directory without an index file shows the name of every file in it — working copies, material not yet published, administrative files whose purpose their name gives away. For an attacker it is a place to read the contents instead of guessing them.

  Remediation steps

  1. nginx has listings off by default; if they were turned on, set autoindex off;.
  2. In Apache, remove Indexes from that directory's Options, so Options -Indexes.
  3. Confirm with curl -s https://example.com/uploads/ | head returning no listing.
  4. While you are there, look at what working files are sitting in the web root.
  View evidence (1 in total)

  • httpsubject example.comcollected 01/09/2026 09:00 GMT+9

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    evidence id http:http.probes:example.com

• Cleartext legacy protocols stopped

  Engine output (verbatim)

  no issues across indexed hosts

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  FTP and telnet carry credentials and content in the clear, so anyone on the path reads the username and password as they go by. TFTP has no authentication at all: knowing a filename is enough to fetch it. Encrypted replacements have been available for decades.

  Remediation steps

  1. Replace FTP (21) with SFTP or FTPS and telnet (23) with SSH, then stop the old daemons — systemctl disable --now vsftpd, systemctl disable --now telnet.socket — and block the ports in the firewall as well.
  2. Keep TFTP (69/udp) to device bootstrapping on the internal network only.
  3. Confirm from outside that nmap -Pn -p 21,23 <ip> and nmap -Pn -sU -p 69 <ip> report nothing open.
  View evidence (0 in total)

  This item cites no evidence id.

• Orchestration APIs not exposed

  Engine output (verbatim)

  no issues across indexed hosts

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  The Docker API (2375, 2376), the Kubernetes API server (6443) and the kubelet (10250) all lead directly to running arbitrary containers on the host. Port 2375 in particular has neither encryption nor authentication, so anyone who can reach it has effectively root on that machine. This is how a whole platform is taken at once.

  Remediation steps

  1. Do not expose these APIs to the internet.
  2. Drop -H tcp:// from dockerd and listen on the Unix socket only; where remote access is genuinely needed, use 2376 with mutual TLS and restrict the source as well.
  3. Keep the Kubernetes API server on a restricted network or behind a bastion, and disable anonymous kubelet access with --anonymous-auth=false.
  4. Confirm from outside that nmap -Pn -p 2375,2376,6443,10250 <ip> reports nothing open.
  View evidence (0 in total)

  This item cites no evidence id.

• Small exposed service footprint

  Engine output (verbatim)

  no issues across indexed hosts

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Every additional listening service is another thing to patch and another version banner an attacker can match against an exploit. A long open-port list usually contains something nobody remembers deciding to expose.

  Remediation steps

  1. List what is actually listening with ss -tulpn, and for each entry decide one of three things: switch it off (systemctl disable --now <unit>), bind it to loopback or an internal interface, or keep it public deliberately.
  2. Then make the edge default-deny (ufw default deny incoming plus explicit allows, or a security group listing only the ports you named).
  3. This check warns above 10 open ports on any one host, so confirm from outside with nmap -Pn --top-ports 1000 <ip> against each host and check it comes back at 10 or fewer.
  Related terms

  • banner - A reply a server sends to whoever connects to it, revealing the name and version of the software it runs.
  • security group - A cloud provider's mechanism for allowing or denying traffic based on where it comes from and where it is going.
  View evidence (0 in total)

  This item cites no evidence id.

• No remote desktop ports exposed

  Engine output (verbatim)

  no issues across indexed hosts

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  RDP and VNC reachable from the internet mean a constant stream of credential guessing. RDP has repeatedly carried pre-authentication remote code execution flaws, so exposure alone is dangerous; VNC can be configured to hand over the screen with no authentication at all.

  Remediation steps

  1. Do not expose RDP (3389) or VNC (5900) to the internet.
  2. Put them behind a VPN or a bastion host and restrict the source in the firewall: with ufw, add ufw allow from 203.0.113.0/24 to any port 3389 proto tcp and then ufw deny 3389, checking ufw status numbered first for an unconditional allow that would win over it.
  3. Use a security group for the same effect in a cloud.
  4. Confirm from outside that nmap -Pn -p 3389,5900 <ip> returns filtered rather than open.
  Related terms

  • brute-force attack - Trying password or credential combinations one after another until one happens to work.
  View evidence (0 in total)

  This item cites no evidence id.

• No internal files are served

  Engine output (verbatim)

  none of the checked sensitive paths is served

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A readable `.git/config` often means the whole repository can be retrieved. A `.env` file contains database credentials and API keys as they are. Both get published by a deployment mistake, and attackers scan for them constantly. Once one has been read, the credentials in it have to be treated as handed over.

  Remediation steps

  1. Remove the files from the web root first.
  2. Then rotate every credential they contained, on the assumption they were read — deleting the file does not invalidate what has already been fetched.
  3. To stop it recurring, refuse dot-prefixed paths at the web server: location ~ /\. { deny all; } in nginx, <FilesMatch "^\.">Require all denied</FilesMatch> in Apache.
  4. The durable fix is deploying built artefacts rather than copying the repository.
  Related terms

  • private key - A value meant to be known only to its holder, used to prove identity or decrypt data. Anyone who obtains a copy can act as the holder.
  • brute-force attack - Trying password or credential combinations one after another until one happens to work.
  View evidence (1 in total)

  • httpsubject example.comcollected 01/09/2026 09:00 GMT+9

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    evidence id http:http.probes:example.com

• No file sharing ports exposed

  Engine output (verbatim)

  no issues across indexed hosts

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  SMB was never meant to face the internet. Exposed, it offers share enumeration and credential guessing, and has carried widely exploited pre-authentication remote code execution flaws. It is one of the best-known entry points for ransomware.

  Remediation steps

  1. Block SMB (139, 445) at the internet edge — restrict it to the internal network in the firewall, or drop it at the perimeter.
  2. Where files genuinely have to reach outside parties, use SFTP or HTTPS rather than SMB.
  3. On Windows, disable File and Printer Sharing for the Public firewall profile.
  4. Confirm from outside that nmap -Pn -p 139,445 <ip> reports nothing open.
  Related terms

  • brute-force attack - Trying password or credential combinations one after another until one happens to work.
  View evidence (0 in total)

  This item cites no evidence id.

• SNMP not exposed

  Engine output (verbatim)

  no issues across indexed hosts

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  SNMP v1 and v2c send their community string in the clear, and the default `public` is often still there. Read access alone hands over running processes, network layout and device models and versions — the reconnaissance stage, done for the attacker. Being UDP, it is also used to amplify spoofed traffic at third parties.

  Remediation steps

  1. Block SNMP (161/udp) at the internet edge and restrict it to your monitoring hosts.
  2. Retire v1 and v2c in favour of v3, which authenticates and encrypts: in net-snmp, remove the rocommunity lines from snmpd.conf and define users with createUser and rouser.
  3. Do not leave the default public and private community strings in place.
  4. Confirm from a host other than the monitoring server that nmap -Pn -sU -p 161 <ip> does not report open.
  View evidence (0 in total)

  This item cites no evidence id.

• No CVEs matched against the published version

  Engine output (verbatim)

  no issues across indexed hosts

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  These CVEs come from a public index matching the version you publish in your own banner against a CVE database. That method cannot see distribution backports: Ubuntu and Debian apply the fix and leave the upstream version number alone, so a patched host and an unpatched one are the same string from outside. Measured on a real host — nginx 1.24.0-2ubuntu7.17 carries the CVE-2025-23419 and CVE-2023-44487 patches and was listed for both anyway. That is not a reason to ignore the list: the same index is used as a target list, and CVEs well known enough to be indexed usually have working exploit code.

  Remediation steps

  1. Confirm on the host first.
  2. On deb-based systems, read the installed version with dpkg -l <package> and check for the CVE in the packaging changelog: zcat /usr/share/doc/<package>/changelog.Debian.gz | grep CVE-XXXX-NNNNN, then check that the release carrying the patch is at or below your installed version.
  3. On rpm-based systems, rpm -q --changelog <package> | grep CVE-XXXX-NNNNN.
  4. If the patch is there, this host does not carry that CVE — the index will keep showing it until its next scan, so do not wait for it to clear.
  5. If it is not, update (apt update && apt upgrade or dnf upgrade followed by a service restart; for containers, bump the image and redeploy).
  6. Where no fix exists, apply the vendor's mitigation, and if there is none, take the service off the public interface until there is.
  Related terms

  • CVE - A shared reference number assigned to a specific publicly known software flaw.
  • banner - A reply a server sends to whoever connects to it, revealing the name and version of the software it runs.
  • backport - A distributor applying only the fix to an older release. The version number does not move, so from outside there is no way to tell a patched build from an unpatched one.
  View evidence (0 in total)

  This item cites no evidence id.

• Short-lived certificates (ready for 47-day lifetimes)

  Engine output (verbatim)

  certificate lifetime 90 days

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A one-year certificate is a year in which a stolen private key stays usable, because revocation is unreliable in practice and lifetime is the real limit. The CA/Browser Forum is also stepping maximum lifetimes down towards 47 days, and a manual renewal process that copes at one year will not.

  Remediation steps

  1. Do not shorten the lifetime by hand — automate issuance with ACME so lifetime stops being an operational cost: certbot on its systemd timer, acme.sh in cron, or the managed certificates of your CDN or load balancer.
  2. Reload from a hook (--deploy-hook "systemctl reload nginx") and prove the unattended path with certbot renew --dry-run.
  3. Confirm on the next issued certificate that openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates shows a notBefore-to-notAfter span of 90 days or less.
  Related terms

  • private key - A value meant to be known only to its holder, used to prove identity or decrypt data. Anyone who obtains a copy can act as the holder.
  • revocation - Declaring an already-issued certificate invalid before its stated expiry. Nothing guarantees that everyone receiving it will check that declaration.
  • ACME challenge - An exchange used by automated certificate issuance to confirm that the requester genuinely controls the domain.
  View evidence (1 in total)

  • CT logs (crt.sh + Cert Spotter)subject example.comcollected 01/09/2026 09:00 GMT+9

    certificates

    1

    example.com, www.example.com

    C=US, O=Let's Encrypt, CN=R11 · 2099-01-01 → 2099-04-01

    evidence id crtsh:crtsh.certs:example.com

• Post-quantum key exchange accepted

  Engine output (verbatim)

  hybrid post-quantum key exchange accepted

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Traffic recorded today can be decrypted in bulk once a quantum computer can break the elliptic-curve key exchange protecting it — harvest now, decrypt later. A hybrid key exchange (X25519MLKEM768) removes the value of storing it, without weakening anything today.

  Remediation steps

  1. You need a TLS stack that can offer the hybrid group: OpenSSL 3.5+ and recent BoringSSL provide X25519MLKEM768 by default.
  2. Build nginx against it and set ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1; — check support first with openssl version, because an older OpenSSL refuses to start on an unknown curve.
  3. On a CDN it is usually already on, or a zone setting.
  4. Confirm that openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null completes and reports Negotiated TLS1.3 group: X25519MLKEM768.
  Related terms

  • post-quantum cryptography - Cryptography designed to remain unbroken even against a future quantum computer.
  • hybrid key exchange - Agreeing on a session key using today's method and a forward-looking method at the same time, so a break in either one alone is not enough.
  • harvest now, decrypt later - Storing today's traffic that cannot yet be read, on the expectation of reading it in bulk once stronger decryption capability exists later.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• Route origins covered by valid ROAs

  Engine output (verbatim)

  all prefixes RPKI valid

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  With no ROA, anyone who can speak BGP may announce your address space and pull your traffic to themselves — and once there, answer an ACME HTTP challenge and obtain a genuine certificate for your domain. Networks that drop RPKI-invalid routes reject such an announcement.

  Remediation steps

  1. This is done by whoever holds the IP space, at the RIR, not on the server.
  2. If you hold the prefix, create a ROA for each prefix and origin AS in your RIR portal (JPNIC, APNIC, RIPE NCC, ARIN), keeping maxLength no longer than you actually announce — a loose maxLength authorises a more-specific hijack.
  3. If the addresses belong to a hosting or cloud provider, they are the holder: ask them to publish ROAs for the prefixes your hosts sit in.
  4. Confirm on RIPEstat or bgp.he.net that the announcement shows as RPKI-valid; propagation takes about an hour.
  Related terms

  • RPKI - A system for registering, with a digital signature, which organisation is allowed to announce the route to a given range of addresses.
  • ROA - A digitally signed statement declaring which organisation may announce the route to a given range of addresses.
  • BGP - The mechanism networks use to tell each other which address ranges they can deliver traffic to.
  • AS number - A number assigned to an organisation that identifies it as a unit when exchanging routes with other networks.
  • IP prefix - A way of writing a contiguous block of addresses as a single range.
  • ACME challenge - An exchange used by automated certificate issuance to confirm that the requester genuinely controls the domain.
  View evidence (1 in total)

  • RIPEstat (RPKI)subject 192.0.2.1collected 01/09/2026 09:00 GMT+9

    Prefix

    192.0.2.0/24

    ASN

    AS64500

    RPKI status

    valid

    evidence id rpki:rpki.prefix:192.0.2.1

• No credentials in the served scripts

  Engine output (verbatim)

  no credential recognised in the 1 scripts read

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A script served to browsers is readable in full by everyone who loads the page. An API key or a private key in it is published. Obfuscation and minification do not change that. It does not stop being valid when you delete it; it was handed over when it was read.

  Remediation steps

  1. Rotate the credentials and revoke the old ones first.
  2. Removing them from the file comes second — the other order leaves a live credential in circulation between deletion and rotation.
  3. Then change the build so server-only values cannot reach the client bundle: the usual cause is a configuration that embeds every build-time environment variable, and the fix is listing explicitly which ones may be published.
  Related terms

  • private key - A value meant to be known only to its holder, used to prove identity or decrypt data. Anyone who obtains a copy can act as the holder.
  • XSS - An attack where a third party sneaks a script into a page that was not meant to contain one, and it runs in a visitor's browser.
  View evidence (1 in total)

  • httpsubject example.comcollected 01/09/2026 09:00 GMT+9

    fetched

    https://example.com/app.js

    observed

    true

    evidence id http:http.scripts:example.com

• robots.txt names no sensitive path

  Engine output (verbatim)

  robots.txt names no sensitive-looking path

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  `robots.txt` is a file anyone can read. `Disallow: /admin/` in it is an instruction about search results, not an access control — what it actually does is state where the administrative area is. It is one of the first files an attacker reads.

  Remediation steps

  1. Take the administrative paths out of robots.txt.
  2. To keep a page out of search results, send X-Robots-Tag: noindex with it or put <meta name="robots" content="noindex"> on it: both reach only a search engine that already fetched the page, rather than publishing a list.
  3. Then put authentication or a source restriction on the path itself.
  4. Hiding is not a control; controlling access is.
  View evidence (1 in total)

  • httpsubject example.comcollected 01/09/2026 09:00 GMT+9

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    evidence id http:http.probes:example.com

• security.txt published

  Engine output (verbatim)

  security.txt found

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  With no stated contact, someone who finds a flaw in your service has to guess an address; reports commonly go nowhere, and the finder either drops it or publishes it. One published contact is the difference between hearing about it first and reading about it.

  Remediation steps

  1. Publish an RFC 9116 plain-text file at https://example.com/.well-known/security.txt with at least Contact: mailto:security@example.com and Expires: (an RFC 3339 timestamp within a year), plus Preferred-Languages: and a Policy: line if you have one.
  2. Serve it over HTTPS as Content-Type: text/plain; charset=utf-8, and diarise refreshing Expires — an expired file counts as invalid.
  3. Most importantly, put a named owner on the mailbox.
  4. Confirm with curl -sI https://example.com/.well-known/security.txt returning 200 and text/plain.
  Related terms

  • security.txt - A plain-text file published at a fixed location stating where someone who finds a flaw should send the report.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    security.txt

    yes

    evidence id http:http.security_txt:example.com

• Production source maps are controlled

  Engine output (verbatim)

  the page advertises no source map

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A source map relates minified script back to the code it was built from. Published with `sourcesContent`, it hands over that pre-minification code itself — variable names, comments, unreleased features, how the internal APIs are called. Everything from development, readable by anyone.

  Remediation steps

  1. Either leave source maps out of the production build or emit them without sourcesContent.
  2. In webpack that is devtool: false; in Vite, build.sourcemap: false.
  3. If you keep them for debugging, put the maps outside what the web server serves (refuse requests for .map) and relate them locally when you need to.
  4. Confirm by opening the URL in a published script's sourceMappingURL and getting a 404.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    HTTP status

    200

    final URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    evidence id http:http.headers:example.com

• DMARC applies to all mail

  Engine output (verbatim)

  DMARC pct absent, so the policy applies to all mail

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  `pct` sets the share of mail the DMARC policy is applied to. At `pct=20`, four out of five forged messages fall outside the policy and reach the inbox even with `p=reject` published. That is a reasonable setting during a staged rollout, but left in place it means the domain is far less protected than the record appears to say.

  Remediation steps

  1. Check in the DMARC aggregate reports that every legitimate sender aligns on DKIM or SPF.
  2. Then remove pct from the _dmarc TXT record, or set pct=100 — 100 is the default when the tag is absent.
  3. Confirm with dig +short TXT _dmarc.example.com showing no pct or pct=100, and watch the next report for legitimate senders that started being rejected.
  Related terms

  • DMARC - A published instruction telling receivers what to do with mail that fails the sender checks: deliver it, flag it, or drop it.
  • aggregate report - A periodic summary that receivers send back describing who has been sending mail claiming to be from a given domain.
  • alignment - The domain shown to the reader as the sender matches the domain that actually passed the sending checks.
  • SPF - A DNS record listing which servers may send mail claiming to be from this domain.
  • DKIM - A digital signature added to outgoing mail so the receiver can tell it was not altered in transit and really came from the claimed sender.
  View evidence (2 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    evidence id dns:dns.mail:example.com

• DMARC record published

  Engine output (verbatim)

  DMARC present

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  SPF and DKIM on their own tell a receiver nothing about what to do with mail that fails them, and give you no visibility. Without a DMARC record, someone can send invoice and password-reset mail as your domain and you will never learn it happened.

  Remediation steps

  1. Publish a TXT record at _dmarc.example.com in monitoring mode first: v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1 (in the zone, the host name is _dmarc).
  2. Wait a few days for the first aggregate reports, use them to enumerate your real senders, and only then tighten the policy.
  3. Confirm with dig +short TXT _dmarc.example.com returning the record.
  Related terms

  • DMARC - A published instruction telling receivers what to do with mail that fails the sender checks: deliver it, flag it, or drop it.
  • SPF - A DNS record listing which servers may send mail claiming to be from this domain.
  • DKIM - A digital signature added to outgoing mail so the receiver can tell it was not altered in transit and really came from the claimed sender.
  • aggregate report - A periodic summary that receivers send back describing who has been sending mail claiming to be from a given domain.
  • TXT record - A type of DNS record that publishes an arbitrary piece of text against a domain name, commonly used to declare configuration.
  View evidence (2 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    evidence id dns:dns.mail:example.com

• DMARC aggregate reporting configured

  Engine output (verbatim)

  DMARC rua present

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  With no `rua` address you receive no aggregate reports at all, so you cannot see who is sending as your domain, cannot tell a spoofing campaign from a forgotten legitimate sender, and have no safe basis for tightening the policy.

  Remediation steps

  1. Add rua=mailto:dmarc@example.com to the _dmarc.example.com TXT record, keeping the existing v= and p= — for example v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; fo=1.
  2. If the mailbox is on another domain, that domain must publish example.com._report._dmarc.<other-domain> with v=DMARC1 or the reports are refused.
  3. The reports are gzipped XML, so point them at a parser or a service you will actually read.
  4. Confirm with dig +short TXT _dmarc.example.com showing rua=, and by receiving a report within a day or two.
  Related terms

  • DMARC - A published instruction telling receivers what to do with mail that fails the sender checks: deliver it, flag it, or drop it.
  • aggregate report - A periodic summary that receivers send back describing who has been sending mail claiming to be from a given domain.
  • TXT record - A type of DNS record that publishes an arbitrary piece of text against a domain name, commonly used to declare configuration.
  View evidence (2 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    evidence id dns:dns.mail:example.com

• DMARC covers subdomains

  Engine output (verbatim)

  DMARC enforces on subdomains (subdomains inherit p=quarantine)

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  An attacker does not need to forge the apex. A sender address at a subdomain that never existed — `billing.example.com` — reads to the recipient as the same organisation. With no `sp` and a permissive `p`, that route is unprotected.

  Remediation steps

  1. Add sp=reject to the _dmarc TXT record.
  2. If no subdomain sends mail, that is all there is to it.
  3. If some do, first confirm in the DMARC aggregate reports that they align on DKIM or SPF, then apply it.
  4. Confirm with dig +short TXT _dmarc.example.com showing sp=reject, and by test-sending from a subdomain that does not exist and seeing it rejected.
  Related terms

  • DMARC - A published instruction telling receivers what to do with mail that fails the sender checks: deliver it, flag it, or drop it.
  • alignment - The domain shown to the reader as the sender matches the domain that actually passed the sending checks.
  • aggregate report - A periodic summary that receivers send back describing who has been sending mail claiming to be from a given domain.
  • phishing - A scam message impersonating someone trusted, aiming to trick the reader into typing a password or other secret themselves.
  • apex domain - A domain name written on its own, with no leading label such as www.
  View evidence (2 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    evidence id dns:dns.mail:example.com

• MTA-STS declared in DNS

  Engine output (verbatim)

  MTA-STS declared

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  SMTP still delivers in cleartext when STARTTLS is absent or the certificate does not verify, so an on-path attacker can strip the encryption and read or alter your mail. MTA-STS is the declaration that makes senders refuse that downgrade — and without the DNS record, senders never go looking for the policy.

  Remediation steps

  1. Publish a TXT record at _mta-sts.example.com reading v=STSv1; id=20260905000000.
  2. The id is an arbitrary version string you must change whenever the policy changes, or senders keep using their cached copy.
  3. This is only half of it: the policy file at https://mta-sts.example.com/.well-known/mta-sts.txt has to exist too.
  4. Confirm with dig +short TXT _mta-sts.example.com.
  Related terms

  • MTA-STS - An instruction to sending mail servers to refuse delivery over a connection that cannot be encrypted.
  • STARTTLS - A way of switching a plaintext mail conversation over to an encrypted one partway through. The switch signal itself travels in the clear, so it can be stripped by someone on the path.
  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  • TXT record - A type of DNS record that publishes an arbitrary piece of text against a domain name, commonly used to declare configuration.
  View evidence (2 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    evidence id dns:dns.mail:example.com

• MX hosts have matching reverse DNS

  Engine output (verbatim)

  every MX host has forward-confirmed reverse DNS

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Most receivers decide whether a sending host looks legitimate by checking that the address's reverse DNS resolves back to that same address. A sender that does not match is treated as spam or refused at connection time — before SPF and DKIM, however well configured, get a chance to matter.

  Remediation steps

  1. Reverse records are set by whoever assigned the address: the cloud provider or ISP.
  2. Look for a reverse-DNS field in their control panel, or ask them.
  3. Use the MX host's own name, and confirm that name resolves to the same address.
  4. Check with dig +short -x <IP> returning a name, and dig +short <that name> returning the original address.
  Related terms

  • authoritative name server - A server that holds the official answers for a domain and responds to lookups from everyone else.
  View evidence (2 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    evidence id dns:dns.mail:example.com

• Mail exchangers offer STARTTLS

  Engine output (verbatim)

  all 1 mail exchangers offer STARTTLS

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Mail to an exchanger that does not offer STARTTLS crosses the network in the clear — subject, body and attachments readable at every hop. That covers the invoice a supplier sent and the password-reset notice alike. The sending side cannot demand encryption; its only choice is to send in the clear or not send.

  Remediation steps

  1. In Postfix, set smtpd_tls_security_level = may in main.cf alongside smtpd_tls_cert_file and smtpd_tls_key_file.
  2. In Exim, tls_certificate and tls_privatekey.
  3. Get the certificate for the exchanger's own host name.
  4. Hosted mail services have it on by default.
  5. Confirm with openssl s_client -starttls smtp -connect mail.example.com:25 completing the handshake.
  Related terms

  • STARTTLS - A way of switching a plaintext mail conversation over to an encrypted one partway through. The switch signal itself travels in the clear, so it can be stripped by someone on the path.
  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  • MTA-STS - An instruction to sending mail servers to refuse delivery over a connection that cannot be encrypted.
  View evidence (3 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    evidence id dns:dns.mail:example.com

  • smtpsubject example.comcollected 01/09/2026 09:00 GMT+9

    evidence id smtp:smtp.mx:example.com

• Mail exchangers present a valid certificate

  Engine output (verbatim)

  all 1 exchangers present a valid certificate

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  STARTTLS with a certificate whose name does not match, or that has expired, or that reaches no trusted authority, leaves the sender unable to establish who answered. Most senders deliver anyway. The traffic is encrypted, but an attacker interposing on the path goes unnoticed, which is most of what the encryption was for.

  Remediation steps

  1. Obtain a certificate for the exchanger's own host name — what dig +short MX example.com returns — and install it on the SMTP service.
  2. Reusing the web certificate works only if that host name is in its subjectAltName.
  3. Include the intermediates.
  4. Where MTA-STS is enforced, this fault becomes delivery failure outright.
  5. Confirm that openssl s_client -starttls smtp -connect mail.example.com:25 reports Verify return code: 0.
  Related terms

  • STARTTLS - A way of switching a plaintext mail conversation over to an encrypted one partway through. The switch signal itself travels in the clear, so it can be stripped by someone on the path.
  • Certificate Authority - A company that verifies a server's identity and then issues it a certificate.
  • MTA-STS - An instruction to sending mail servers to refuse delivery over a connection that cannot be encrypted.
  • DANE - A way of using signed DNS records to let a sending mail server check that the delivery destination is presenting its genuine key.
  View evidence (3 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    evidence id dns:dns.mail:example.com

  • smtpsubject example.comcollected 01/09/2026 09:00 GMT+9

    evidence id smtp:smtp.mx:example.com

• SPF stays within the lookup limit

  Engine output (verbatim)

  SPF costs 1 of the 10 permitted DNS lookups

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A receiver evaluating SPF is permitted ten DNS lookups (RFC 7208 §4.6.4). Past that it abandons the evaluation, and SPF does nothing whatever the record says. Each sending service added brings another include, so records drift over the limit without anyone noticing.

  Remediation steps

  1. Remove includes you no longer use.
  2. For providers whose sending addresses are fixed, replacing the include with the ip4: addresses removes a lookup each.
  3. If it still does not fit, move sending onto a subdomain of its own (mail.example.com) and keep the apex record light.
  4. Public validators will count the lookups for you.
  5. Afterwards check the DMARC aggregate reports still show legitimate senders passing.
  Related terms

  • SPF - A DNS record listing which servers may send mail claiming to be from this domain.
  • aggregate report - A periodic summary that receivers send back describing who has been sending mail claiming to be from a given domain.
  View evidence (2 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    evidence id dns:dns.mail:example.com

• SPF avoids the ptr mechanism

  Engine output (verbatim)

  SPF uses no ptr mechanism

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  The ptr mechanism makes the receiver do a reverse lookup on the sending IP and then a forward lookup on whatever it returns. RFC 7208 §5.5 asks receivers not to use it and publishers not to publish it, because it is expensive and the answer is unreliable. A receiver that cannot resolve the reverse zone ignores the mechanism, which can leave a legitimate sender rejected.

  Remediation steps

  1. Replace whatever ptr was standing in for with the actual addresses or the provider's include.
  2. Your own servers become ip4:203.0.113.10 and the like; a hosted service becomes the include: its documentation gives.
  3. Confirm that dig +short TXT example.com | grep spf1 no longer shows ptr, and that legitimate senders still pass SPF in the next DMARC aggregate report.
  Related terms

  • SPF - A DNS record listing which servers may send mail claiming to be from this domain.
  • aggregate report - A periodic summary that receivers send back describing who has been sending mail claiming to be from a given domain.
  View evidence (2 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    evidence id dns:dns.mail:example.com

• SPF record published

  Engine output (verbatim)

  SPF present

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Without SPF, no receiver has any way to tell whether mail claiming to be from your domain actually left a server you use. Anyone can send invoices, password resets and bank-detail changes under your domain name, and they land in the inbox.

  Remediation steps

  1. Publish exactly one TXT record at the apex, listing every system that sends as this domain and closing with a restrictive all — for example v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all.
  2. There must be only one SPF record (two produce a permerror), and the DNS lookups from include:, a and mx must total 10 or fewer.
  3. Confirm that dig +short TXT example.com | grep spf1 returns a single record, and that a test message to an external receiver shows spf=pass in its Authentication-Results header.
  Related terms

  • SPF - A DNS record listing which servers may send mail claiming to be from this domain.
  • TXT record - A type of DNS record that publishes an arbitrary piece of text against a domain name, commonly used to declare configuration.
  View evidence (2 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    evidence id dns:dns.mail:example.com

• Exactly one SPF record

  Engine output (verbatim)

  exactly one SPF record

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  With two or more SPF records, a receiver does not pick one — it abandons SPF evaluation entirely (RFC 7208 §3.2, permerror). Each record can be perfectly correct and the domain still has no working sender authorisation. The usual cause is adding a new TXT record for a new sending system instead of extending the existing one.

  Remediation steps

  1. List what is published with dig +short TXT example.com | grep spf1.
  2. Merge every include:, ip4:, ip6:, a and mx term into a single record, dropping duplicates, and keep the strictest trailing all mechanism.
  3. Publish the merged record and delete the others.
  4. Confirm the same dig returns exactly one line, and that legitimate senders go back to SPF pass in the next DMARC aggregate report.
  Related terms

  • SPF - A DNS record listing which servers may send mail claiming to be from this domain.
  • TXT record - A type of DNS record that publishes an arbitrary piece of text against a domain name, commonly used to declare configuration.
  • aggregate report - A periodic summary that receivers send back describing who has been sending mail claiming to be from a given domain.
  View evidence (2 in total)

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    A

    192.0.2.1

    NS

    ns1.example.net - ns2.example.net

    MX

    mail.example.com

    TXT

    v=spf1 mx ~all

    evidence id dns:dns.host:example.com

  • DNS answersubject example.comcollected 01/09/2026 09:00 GMT+9

    SPF

    v=spf1 mx ~all

    DMARC

    v=DMARC1; p=quarantine; rua=mailto:d@example.com

    MTA-STS

    v=STSv1

    evidence id dns:dns.mail:example.com

• The domain is not on a block list

  Engine output (verbatim)

  the domain is on none of the 1 lists asked

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A listed domain name has its mail refused and its URLs stripped from other people's mail, whoever sends them. Unlike an address listing, changing where you send from does not avoid it. The usual causes are a compromised site redirecting visitors, or a wave of forged mail — and a listing follows even when you are the victim.

  Remediation steps

  1. Check first whether the site has been altered and whether unintended redirects have been planted.
  2. Where forgery is the cause, tighten SPF, DKIM and DMARC and move to p=reject.
  3. With the cause removed, follow the list's delisting procedure.
  4. Confirm that dig +short example.com.dbl.spamhaus.org returns nothing.
  Related terms

  • DMARC - A published instruction telling receivers what to do with mail that fails the sender checks: deliver it, flag it, or drop it.
  • phishing - A scam message impersonating someone trusted, aiming to trick the reader into typing a password or other secret themselves.
  • subdomain takeover - Registering an outside service that a subdomain still points to after it was abandoned, so the attacker now controls what that subdomain serves.
  View evidence (1 in total)

  • dns-repsubject example.comcollected 01/09/2026 09:00 GMT+9

    ip_lists_asked

    zen.spamhaus.org

    domain_lists_asked

    dbl.spamhaus.org

    evidence id dns-rep:dns.reputation:example.com

• Addresses are not on a block list

  Engine output (verbatim)

  no address is listed on any of the 1 lists asked

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  An address on a block list stops delivering mail. Many receivers consult the same lists, so the effect is not confined to one correspondent. The cause is nearly always at your end: a compromised machine inside, a misconfigured forwarder, a virtual server left running after it was cancelled.

  Remediation steps

  1. Remove the cause before requesting delisting.
  2. A delisting with the cause still in place is followed by a relisting within days, and repeated cycles end with the request no longer being accepted.
  3. Look at what that address is sending, and check for unauthenticated relaying and infected machines.
  4. Then follow each list's own procedure (Spamhaus at https://check.spamhaus.org/).
  5. Confirm the same query comes back unlisted.
  Related terms

  • SPF - A DNS record listing which servers may send mail claiming to be from this domain.
  • DKIM - A digital signature added to outgoing mail so the receiver can tell it was not altered in transit and really came from the claimed sender.
  • DMARC - A published instruction telling receivers what to do with mail that fails the sender checks: deliver it, flag it, or drop it.
  View evidence (1 in total)

  • dns-repsubject example.comcollected 01/09/2026 09:00 GMT+9

    ip_lists_asked

    zen.spamhaus.org

    domain_lists_asked

    dbl.spamhaus.org

    evidence id dns-rep:dns.reputation:example.com

• External dependencies are healthy

  Engine output (verbatim)

  all 1 external dependencies answer with a valid certificate

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  An external resource the page loads that cannot be fetched means the features depending on it do not work. A certificate that does not verify makes the browser refuse the load outright. Providers shut down and move without notice, and nothing about that is visible from your side. Dependency domains have lapsed and been registered by someone else.

  Remediation steps

  1. Replace what no longer answers with a current provider, or serve it yourself — and if you self-host, decide how it gets updated.
  2. Where you keep an external one, an integrity attribute (web.sri) stops it executing if the provider's file is swapped.
  3. Check the browser's network tab periodically for failed requests during page load.
  Related terms

  • CDN - A provider's network of stand-in servers spread across many locations, used to serve content from somewhere close to each visitor.
  • subdomain takeover - Registering an outside service that a subdomain still points to after it was abandoned, so the attacker now controls what that subdomain serves.
  View evidence (1 in total)

  • httpsubject example.comcollected 01/09/2026 09:00 GMT+9

    observed

    true

    evidence id http:http.cdn:example.com

• JavaScript library versions

  Engine output (verbatim)

  the 1 recognised library versions are all at or above their advisory floor

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Older JavaScript libraries carry published vulnerabilities — typically, as in older jQuery, ones that allow script injection wherever user input is handled. The code runs in the visitor's browser with your site's privileges.

  Remediation steps

  1. Update the library.
  2. Loading from a CDN means changing the version in the URL and replacing the integrity attribute alongside it (web.sri).
  3. Serving it yourself means updating through the package manager and rebuilding.
  4. Where the finding says unconfirmed, the version was read from the file name — the contents may well have been replaced, so check the version of what you actually serve.
  Related terms

  • CVE - A shared reference number assigned to a specific publicly known software flaw.
  • XSS - An attack where a third party sneaks a script into a page that was not meant to contain one, and it runs in a visitor's browser.
  • backport - A distributor applying only the fix to an older release. The version number does not move, so from outside there is no way to tell a patched build from an unpatched one.
  View evidence (1 in total)

  • httpsubject example.comcollected 01/09/2026 09:00 GMT+9

    fetched

    https://example.com/app.js

    observed

    true

    evidence id http:http.scripts:example.com

• External scripts are accounted for

  Engine output (verbatim)

  the page runs script from 1 external hosts: [cdn.example.net]

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Every script loaded from elsewhere runs on your page with your site's privileges. It can read what visitors type into forms and rewrite what they see. Advertising and analytics tags tend to be added by different teams at different times, and the full list is often something nobody holds.

  Remediation steps

  1. This item reports an observation and deducts nothing.
  2. Read the list and remove what you cannot account for: tags whose purpose is unclear, providers whose contract has ended, duplicated analytics.
  3. Give what remains an integrity attribute (web.sri), and restrict script-src in the Content-Security-Policy to the list, so an unplanned addition stops rather than runs.
  Related terms

  • CSP - A declared list of the scripts allowed to run and the outside locations allowed to be loaded on a page.
  • XSS - An attack where a third party sneaks a script into a page that was not meant to contain one, and it runs in a visitor's browser.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    HTTP status

    200

    final URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    evidence id http:http.headers:example.com

• External resources are fetched securely

  Engine output (verbatim)

  all 1 external resources are fetched over HTTPS

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Fetching an external resource in the clear lets anyone on the path replace it. What they replace is code that runs on your page — to the visitor, something your site did. Before the question of whether the provider is trustworthy comes the question of whether the delivery is protected at all.

  Remediation steps

  1. Change every external reference to https://.
  2. Where a provider offers no HTTPS, reconsider the dependency itself: a delivery host without HTTPS in 2026 is very likely unmaintained.
  3. Confirm in the browser's network tab that loading the page produces no plain-HTTP external request.
  Related terms

  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    HTTP status

    200

    final URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    evidence id http:http.headers:example.com

• No weak cipher suites

  Engine output (verbatim)

  no weak cipher suites

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  The suites this flags — RC4, 3DES, export grade, and anything without forward secrecy — can be broken or downgraded into with published attacks, letting an on-path attacker recover session data. Without forward secrecy, recorded sessions also become readable the day the server key leaks.

  Remediation steps

  1. Narrow the list rather than reordering it.
  2. nginx: ssl_protocols TLSv1.2 TLSv1.3; with ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; and ssl_prefer_server_ciphers off;.
  3. Apache: the same list in SSLCipherSuite with SSLHonorCipherOrder off.
  4. Validate with nginx -t and reload.
  5. Confirm with nmap --script ssl-enum-ciphers -p 443 example.com (or testssl.sh example.com) listing nothing outside that set.
  Related terms

  • cipher suite - The combination of cryptographic methods used to set up an encrypted connection.
  • forward secrecy - A property where each session uses a throwaway key, so a server key stolen later cannot unlock sessions recorded in the past.
  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• Key exchange gives forward secrecy

  Engine output (verbatim)

  the negotiated suite has forward secrecy

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Without forward secrecy, the traffic can be decrypted from the server's private key alone. An attacker who records today's sessions and obtains that key years later can read every one of them. ECDHE derives a throwaway key per connection, so a key that leaks afterwards opens nothing that already happened.

  Remediation steps

  1. Permit only suites that use ECDHE.
  2. In nginx: ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; with ssl_prefer_server_ciphers on;.
  3. In Apache, the same list in SSLCipherSuite alongside SSLHonorCipherOrder on.
  4. Every TLS 1.3 suite has forward secrecy by specification, so enabling 1.3 is itself part of the fix.
  5. Confirm with openssl s_client -connect example.com:443 </dev/null 2>/dev/null | grep -i cipher showing an ECDHE or TLS 1.3 suite.
  Related terms

  • forward secrecy - A property where each session uses a throwaway key, so a server key stolen later cannot unlock sessions recorded in the past.
  • cipher suite - The combination of cryptographic methods used to set up an encrypted connection.
  • harvest now, decrypt later - Storing today's traffic that cannot yet be read, on the expectation of reading it in bulk once stronger decryption capability exists later.
  • private key - A value meant to be known only to its holder, used to prove identity or decrypt data. Anyone who obtains a copy can act as the holder.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• TLS compression is off

  Engine output (verbatim)

  the server selects no compression even when it is offered

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  With TLS compression on, the length of the encrypted traffic gives away its contents. In the attack known as CRIME, someone who can inject known text into the same connection and watch the length change recovers a cookie one character at a time. The cipher is not broken; compression is what makes the length carry information.

  Remediation steps

  1. Turn TLS compression off.
  2. OpenSSL 1.1.0 and later disable it by default, and TLS 1.3 removed it from the specification.
  3. Where it is on, add NoCompression to Options in openssl.cnf or disable it explicitly in the server's own configuration.
  4. Allowing only TLS 1.2 and above removes the problem structurally.
  5. Confirm with openssl s_client -connect example.com:443 </dev/null 2>/dev/null | grep Compression reporting NONE.
  Related terms

  • cipher suite - The combination of cryptographic methods used to set up an encrypted connection.
  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• Legacy TLS versions disabled

  Engine output (verbatim)

  no obsolete TLS version accepted

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  TLS 1.0 and 1.1 have known cryptographic and implementation weaknesses that give an attacker a foothold for decrypting or tampering with traffic. Major browsers already refuse them, so leaving them enabled buys nothing.

  Remediation steps

  1. On nginx set ssl_protocols TLSv1.2 TLSv1.3; (drop TLSv1 and TLSv1.1).
  2. On Apache, SSLProtocol -all +TLSv1.2 +TLSv1.3.
  3. Afterwards, handshake against the host with TLS 1.0 and confirm it is refused.
  Related terms

  • TLS - A way of encrypting a connection so its contents cannot be read or altered along the way. It is what runs underneath HTTPS on the web.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• Secure renegotiation is supported

  Engine output (verbatim)

  the server states RFC 5746 secure renegotiation

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Renegotiation was originally specified with a flaw: an attacker who establishes a connection first, sends data of their choosing, and then splices the visitor's connection onto it, has the server receive a request the visitor never made. RFC 5746 adds an extension confirming that both halves are the same connection. A server that does not offer it either does not implement it or is running a version from before it existed.

  Remediation steps

  1. Update the server software to OpenSSL 0.9.8m or later, or an equivalent.
  2. Any current distribution's stock build already has it, so its absence means either a very old version is running or renegotiation is disabled outright.
  3. The latter is fine, but is still worth confirming the version.
  4. Check with openssl s_client -connect example.com:443 </dev/null 2>/dev/null | grep -i renegotiation reporting Secure Renegotiation IS supported.
  Related terms

  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  • TLS - A way of encrypting a connection so its contents cannot be read or altered along the way. It is what runs underneath HTTPS on the web.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• TLS 1.3 is available

  Engine output (verbatim)

  TLS 1.3 negotiated

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  TLS 1.3 removed the broken cipher suites from the specification outright and made forward secrecy mandatory in key exchange. A TLS 1.2-only configuration is not broken today, but it leaves room for a configuration mistake to cost real security. It also completes the handshake in one fewer round trip.

  Remediation steps

  1. In nginx, set ssl_protocols TLSv1.2 TLSv1.3;.
  2. In Apache, SSLProtocol -all +TLSv1.2 +TLSv1.3.
  3. Both need OpenSSL 1.1.1 or newer, so update the server itself first if it is older.
  4. After a reload, confirm that openssl s_client -connect example.com:443 -tls1_3 </dev/null completes the handshake.
  Related terms

  • TLS - A way of encrypting a connection so its contents cannot be read or altered along the way. It is what runs underneath HTTPS on the web.
  • cipher suite - The combination of cryptographic methods used to set up an encrypted connection.
  • forward secrecy - A property where each session uses a throwaway key, so a server key stolen later cannot unlock sessions recorded in the past.
  View evidence (1 in total)

  • TLS probe (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    supported versions

    TLS1.2 - TLS1.3

    weak cipher

    no

    issuer

    C=US, O=Let's Encrypt, CN=R11

    expires

    2099-04-01

    verified

    yes

    evidence id tls:tls.probe:example.com

• Cookies state a SameSite policy

  Engine output (verbatim)

  every cookie states a SameSite policy

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  SameSite decides whether a cookie rides along on requests coming from other sites. With no attribute the default differs between browsers and has changed between versions. Cross-site request forgery — an attacker's page making the visitor's browser perform an action — is largely closed by this one attribute.

  Remediation steps

  1. Default to SameSite=Lax: sent on ordinary navigation, withheld on a cross-site POST.
  2. Use SameSite=None; Secure only for cookies genuinely embedded on other sites.
  3. None without Secure is rejected by browsers outright.
  4. PHP: session.cookie_samesite = "Lax".
  5. Express: cookie: { sameSite: 'lax' }.
  6. Rails: config.action_dispatch.cookies_same_site_protection = :lax.
  7. Confirm with curl -sI https://example.com | grep -i set-cookie showing SameSite on every line.
  Related terms

  • phishing - A scam message impersonating someone trusted, aiming to trick the reader into typing a password or other secret themselves.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    HTTP status

    200

    final URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    evidence id http:http.headers:example.com

• Cookies carry the Secure attribute

  Engine output (verbatim)

  every cookie is set with Secure

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A cookie without Secure is sent over plain HTTP too. Even on a site served only over HTTPS, making the browser fetch one image from `http://` on the same domain puts the session cookie on the wire. Anyone on the shared Wi-Fi or an intermediate hop can read it and become that user.

  Remediation steps

  1. Set Secure wherever cookies are issued.
  2. PHP: session.cookie_secure = 1 in php.ini.
  3. Express: app.use(session({ cookie: { secure: true } })).
  4. Rails: config.force_ssl = true covers it.
  5. Behind a reverse proxy, some frameworks omit Secure because they do not see HTTPS — pass X-Forwarded-Proto and configure the app to trust it.
  6. Confirm with curl -sI https://example.com | grep -i set-cookie showing Secure on every line.
  Related terms

  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    HTTP status

    200

    final URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    evidence id http:http.headers:example.com

• Cross-origin sharing is controlled

  Engine output (verbatim)

  an arbitrary Origin is not granted access

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A server that returns whatever Origin it was sent lets any site the visitor opens read this site's responses. With credentials also allowed, what they read is the signed-in response. Opening an attacker's page in another tab is enough to carry away what should only appear on your screen.

  Remediation steps

  1. Set Access-Control-Allow-Origin to a fixed value.
  2. Where several origins are legitimate, compare the requested Origin against an allow-list and return it only on a match — never reflect it unchecked.
  3. Add Access-Control-Allow-Credentials: true only where credentials are genuinely needed, and note the wildcard cannot be used with it.
  4. Confirm with curl -sI -H 'Origin: https://example.invalid' https://example.com/ | grep -i access-control and see that origin is not echoed back.
  Related terms

  • phishing - A scam message impersonating someone trusted, aiming to trick the reader into typing a password or other secret themselves.
  View evidence (1 in total)

  • httpsubject example.comcollected 01/09/2026 09:00 GMT+9

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    evidence id http:http.probes:example.com

• Error pages disclose no internals

  Engine output (verbatim)

  the error page discloses no internals

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  An exception trace lists the framework and its version, absolute file paths, internal class and function names. A database error printed as-is gives away the table structure. To an attacker that is the information that decides what to try next. Detailed output enabled during development very often survives into production.

  Remediation steps

  1. Turn detailed errors off in production: display_errors = Off in php.ini, DEBUG = False in Django, config.consider_all_requests_local = false in Rails, APP_DEBUG=false in Laravel.
  2. Serve a common page for 404 and 500 saying no more than "not found".
  3. Keep the detail in the logs, off the screen.
  4. Confirm with both a nonexistent path and a request that causes an error, and see nothing internal in either.
  Related terms

  • banner - A reply a server sends to whoever connects to it, revealing the name and version of the software it runs.
  • CVE - A shared reference number assigned to a specific publicly known software flaw.
  View evidence (1 in total)

  • httpsubject example.comcollected 01/09/2026 09:00 GMT+9

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    evidence id http:http.probes:example.com

• HSTS is enabled

  Engine output (verbatim)

  strict-transport-security present

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Without HSTS, the first request a visitor makes — typing the bare hostname, or following an old `http://` link — leaves in cleartext, and an attacker on that network can intercept it and keep the whole session on plain HTTP or their own TLS proxy. HSTS makes the browser refuse HTTP for your domain after one successful visit.

  Remediation steps

  1. Send Strict-Transport-Security: max-age=31536000; includeSubDomains from the HTTPS listener (nginx: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; inside the server block listening on 443; Apache: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains").
  2. You can back it out by serving max-age=0, but only clients that return over HTTPS pick that up — anyone who never comes back keeps the old pin.
  3. So start around max-age=300, confirm every subdomain has a working certificate, then raise it to a year.
  4. Add preload and submit to hstspreload.org only after that: removal from the preload list takes months.
  5. Confirm with curl -sI https://example.com | grep -i strict-transport-security.
  Related terms

  • HSTS - An instruction that makes a browser remember, after one encrypted visit, never to connect to that site without encryption again.
  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    HTTP status

    200

    final URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    evidence id http:http.headers:example.com

• HSTS meets the preload requirements

  Engine output (verbatim)

  HSTS meets the preload requirements

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  HSTS only takes effect after the browser has seen the header once. The very first visit still goes out over plain HTTP, and that one request is what an on-path attacker takes. Being on the preload list makes the browser force HTTPS from the first visit onward.

  Remediation steps

  1. Serve Strict-Transport-Security: max-age=31536000; includeSubDomains; preload from the apex.
  2. includeSubDomains covers every subdomain, so a single subdomain not served over HTTPS becomes unreachable — verify them all first.
  3. Once the requirements are met, submit the domain at hstspreload.org. Removal takes months.
  4. Run a short max-age for a while and confirm nothing breaks before submitting.
  Related terms

  • HSTS - An instruction that makes a browser remember, after one encrypted visit, never to connect to that site without encryption again.
  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    HTTP status

    200

    final URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    evidence id http:http.headers:example.com

• HTTP redirects to HTTPS

  Engine output (verbatim)

  HTTP redirects to HTTPS

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A site that answers on port 80 without redirecting lets an attacker keep a visitor on plain HTTP for the whole session — reading credentials and cookies and rewriting the page — while the user sees something that works perfectly normally.

  Remediation steps

  1. Make the port-80 server block do nothing but redirect.
  2. nginx: server { listen 80; listen [::]:80; server_name example.com www.example.com; return 301 https://$host$request_uri; }.
  3. Apache: Redirect permanent / https://example.com/ or RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] inside <VirtualHost *:80>.
  4. If you use the ACME HTTP-01 challenge, exempt /.well-known/acme-challenge/ so it stays reachable over HTTP.
  5. Let's Encrypt does follow redirects during validation, including to HTTPS and ignoring certificate errors, so a blanket redirect usually keeps renewing — it breaks when the HTTPS vhost does not serve the same webroot.
  6. Exempting the path removes that dependency.
  7. Confirm with curl -sI http://example.com returning 301 and an https:// Location:.
  Related terms

  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  • ACME challenge - An exchange used by automated certificate issuance to confirm that the requester genuinely controls the domain.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    HTTP status

    200

    final URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    evidence id http:http.headers:example.com

• Request methods are limited

  Engine output (verbatim)

  no writing or diagnostic method is open

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  TRACE echoes the request back, which under the right conditions becomes a route for another script to read credentials. PUT, DELETE and the WebDAV methods allow files to be rewritten or removed when the configuration is wrong. None of them is needed to serve an ordinary website.

  Remediation steps

  1. nginx does not answer TRACE by default; to state it, if ($request_method !~ ^(GET|HEAD|POST)$) { return 405; }.
  2. In Apache, set TraceEnable off and disable the WebDAV modules if you do not use them.
  3. Where writing genuinely is needed, confine it to that location and require authentication.
  4. Confirm with curl -sI -X TRACE https://example.com/ returning 405 or 501.
  View evidence (1 in total)

  • httpsubject example.comcollected 01/09/2026 09:00 GMT+9

    allow

    GET, HEAD, POST, OPTIONS

    options_asked

    true

    trace_answered

    false

    trace_asked

    true

    cors_asked

    true

    not_found_asked

    true

    evidence id http:http.probes:example.com

• No mixed content

  Engine output (verbatim)

  every referenced resource is loaded over HTTPS

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  When an HTTPS page pulls in a resource over plain HTTP, that one request is unprotected — and an attacker on the path can swap the script and take the whole page. Browsers block mixed scripts and stylesheets by default, so it also shows up as the page simply breaking.

  Remediation steps

  1. Rewrite those references from http:// to https://.
  2. Where the source does not offer HTTPS, switch providers or host the file yourself.
  3. If there are many, Content-Security-Policy: upgrade-insecure-requests makes the browser rewrite them, but anything that genuinely has no HTTPS then fails to load — rewriting the references is the durable fix.
  4. Confirm with a browser console free of mixed-content warnings.
  Related terms

  • on-path attacker - Someone positioned somewhere along the network route between a visitor and a server, able to observe or alter the traffic passing through.
  • CSP - A declared list of the scripts allowed to run and the outside locations allowed to be loaded on a page.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    HTTP status

    200

    final URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    evidence id http:http.headers:example.com

• No product version in the server banner

  Engine output (verbatim)

  no product version in the Server or X-Powered-By header

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A response header reading `nginx/1.24.0` lets an attacker narrow down what to try by matching it against a published vulnerability list. Hiding the version fixes nothing on its own, but it does take the host out of the set that indiscriminate scanning selects.

  Remediation steps

  1. In nginx, put server_tokens off; in the http block of nginx.conf.
  2. In Apache, set ServerTokens Prod and ServerSignature Off.
  3. For the application's X-Powered-By, use expose_php = Off in php.ini, or app.disable('x-powered-by') in Express.
  4. After a reload, confirm that curl -sI https://example.com | grep -iE 'server|x-powered-by' shows no version.
  Related terms

  • banner - A reply a server sends to whoever connects to it, revealing the name and version of the software it runs.
  • CVE - A shared reference number assigned to a specific publicly known software flaw.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    HTTP status

    200

    final URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    evidence id http:http.headers:example.com

• Cross-origin resources carry an integrity hash

  Engine output (verbatim)

  every cross-origin script and stylesheet states an integrity hash

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  A script loaded from someone else runs on your page as your page. Providers have been compromised, and so have the networks that deliver their files. An integrity attribute makes the browser refuse to execute anything whose contents do not match the value you stated.

  Remediation steps

  1. Add integrity="sha384-..." and crossorigin="anonymous" to external script and link elements.
  2. Compute the value with openssl dgst -sha384 -binary file.js | openssl base64 -A, though most providers publish it.
  3. The file stops loading when the provider updates it — pin the version in the URL (.../lib@1.2.3/lib.js) and make replacing the hash part of the upgrade procedure.
  4. Confirm with a browser console showing no integrity mismatches.
  Related terms

  • nonce - A value generated fresh each time and trusted only once, used as a one-time proof that something belongs to the current page.
  • XSS - An attack where a third party sneaks a script into a page that was not meant to contain one, and it runs in a visitor's browser.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    HTTP status

    200

    final URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    evidence id http:http.headers:example.com

• X-Content-Type-Options stops MIME sniffing

  Engine output (verbatim)

  X-Content-Type-Options is nosniff

  Score gain: not computed

  Subjects (1 in total, including any that were not inspected)

  • example.com (compliant)

  Risk detail

  Without this header the browser does not trust the response's Content-Type and guesses from the content instead. A file a user uploaded can therefore be executed as script depending on what is inside it — which, on any site with uploads or user posts, is stored script execution.

  Remediation steps

  1. Return X-Content-Type-Options: nosniff on every response.
  2. In nginx add add_header X-Content-Type-Options "nosniff" always; to the http block and run nginx -t && systemctl reload nginx; in Apache use Header always set X-Content-Type-Options "nosniff".
  3. Note that in nginx a single add_header inside a location block cancels every add_header from the server block, so repeat it in any such location.
  4. Confirm with curl -sI https://example.com | grep -i x-content-type-options.
  View evidence (1 in total)

  • HTTP response (active check)subject example.comcollected 01/09/2026 09:00 GMT+9

    HTTP status

    200

    final URL

    https://example.com/

    strict-transport-security

    max-age=63072000; includeSubDomains; preload

    evidence id http:http.headers:example.com