What can an attacker see about your domain right now?

Check your domain

Enter the domain and a work email address on it. Three checks run at once: the DNS records that decide whether anyone can send mail as you, resolved in your own browser; a TLS handshake with every live host we can find under the domain; and one request for each host’s homepage, read for the web application settings a rating assesses. The last two come from our servers. All three finish in under a minute on most estates.

Below the grades sits the BitScore Frontier Index: six risks no rating grades yet, read from the same requests.

Why the email has to match

This is the only tool here that will not answer for any input, and the reason is worth stating plainly. Every other page in this set computes something it already knows: the registers, the thresholds and the clocks are on the page, and the calculator is a convenience. This one opens connections to your servers from ours. That is the single thing on this site that spends somebody else’s resources, and an anonymous scanning endpoint is worth more to an abuser than it is to a visitor.

So the address has to sit on the domain being scanned, or beneath it — you@yourcompany.in may scan yourcompany.in and mail.yourcompany.in, and nothing else. Containment rather than a comparison of registrable domains, because getting the latter wrong fails in the dangerous direction: India alone has co.in, ac.in, gov.in and several more, and a suffix list that misses one turns a match on your domain into a match on everybody’s.

What the web application read covers

Web Application Security became a rated vector in Bitsight’s algorithm update of July 2025, taking the weight Web Application Headers used to carry. Bitsight assesses each application as loaded in a browser, for five things: components with known vulnerabilities, broken authentication, sensitive data exposure, defences against cross-site scripting, and misconfiguration such as cookie flags and HSTS.

This reads what two plain requests can show — port 80, and the homepage over HTTPS — without running the page:

• Misconfiguration. Whether port 80 sends visitors to HTTPS, whether HSTS is set for at least a year, and whether cookies carry Secure and SameSite.
• Cross-site scripting defences. The Content Security Policy, read with CSP Evaluator, the open-source library behind csp-evaluator.withgoogle.com. Only its high-severity findings count: a policy that is report-only, sets no script source, or allows a host known to serve JSONP is reported as no defence.
• Components with known vulnerabilities. Library releases named in the page’s script URLs — jQuery, jQuery UI, Bootstrap, AngularJS, Lodash, Moment.js — against the published advisories for each.
• Data exposure and authentication, from outside. Scripts loaded over plain HTTP on an HTTPS page, a server banner naming its version, and a password field travelling in the clear.

What it does not do matters as much. Nothing is submitted and no script runs, so a library bundled into the site’s own code is not seen — the result says so rather than reporting a clean page. No path is guessed: beyond each homepage, the only requests are the five files the Frontier Index reads from the main site, each one a location published for machines to read. X-Frame-Options and the other headers that made up the retired vector are not graded, because they no longer move a rating. Requests identify themselves as BitScore. Large estates often sit behind a bot-management layer that answers our servers with a challenge; those hosts are listed as blocked and left out of the grade, never counted as a pass.

The BitScore Frontier Index

Six risks that move no security rating today, and will feature in the next breach report.

A rating grades what has been measurable for a decade. The incidents of the last two years came through AI tools nobody inventoried, a key pasted into a chatbot, a CDN that changed hands, a cloud resource deleted while its DNS record stayed. This is our reading of those — BitScore’s own, not Bitsight’s, and shown without letter grades so it cannot be mistaken for a vector. Each lens is exposed, gap, ready or not read, with the basis beside it.

• Agentic AI exposure. Agent builders, model gateways and notebook servers whose login page answers from the internet — Langflow, LiteLLM, n8n, MLflow, Ray all have entries in CISA’s Known Exploited Vulnerabilities catalogue (version 2026.10.08). Server-side keys in the page source, from OpenAI and Anthropic to Stripe and AWS: we never show, store or test the key, only its type and where it sat. Hidden text addressed to AI models. Third-party AI agents on the homepage. And the agent discovery files — MCP’s OAuth protected-resource metadata and an A2A agent card — read for whether they say how callers authenticate.
• Quantum readiness. One extra handshake per host, offering only hybrid X25519 + ML-KEM-768 key exchange. A host that completes it already protects today’s traffic from being decrypted later. Certificates are not graded: no public CA issues a post-quantum one yet.
• Certificate agility. Public certificates issued from 15 March 2027 last at most 100 days, and from 15 March 2029 at most 47 (CA/Browser Forum ballot SC-081). A certificate issued for a year is a renewal done by hand. Plus whether a CAA record limits which authorities may issue for you.
• Dangling DNS. Records that point at something that no longer exists, so whoever claims it answers in your name: a CNAME to a deleted Azure or Elastic Beanstalk resource, a subdomain whose delegation fails to resolve, and — at the apex — a nameserver, MX host or SPF include on a domain that appears to be unregistered. All of it from public resolvers; nothing here touches your servers.
• Script supply chain. Script tags pointing at polyfill.io and the CDNs tied to its operator, and versioned public CDN scripts loaded without an integrity hash — the control PCI DSS 4.0.1 requirement 6.4.3 asks payment pages to evidence.
• Vulnerability disclosure. Whether /.well-known/security.txt exists, names a contact and has not passed its own expiry date (RFC 9116). The person who finds a flaw in your site should not have to guess where to send it.

The five files are /.well-known/security.txt, /robots.txt, /llms.txt, /.well-known/oauth-protected-resource and /.well-known/agent-card.json, read once from the main web host. Each is where a standard or a convention tells automated clients to look. Nothing outside that list is requested. Keys are read from the page source and inline scripts only — a key compiled into a separate bundle is not seen, which is why a ready lens means nothing was found in what was read, not that nothing is there.

Frontier sources read 2026-10-10: the CISA KEV catalogue, the CA/Browser Forum Baseline Requirements §6.3.2, RFC 9116, RFC 9728, the MCP authorization specification (2025-11-25), the A2A specification 1.0, NIST IR 8547 (initial public draft), CERT-In’s BOM guidelines version 2.0, the EU AI Act Article 50 and the EU Cyber Resilience Act Article 71.

Six vectors out of nineteen

A Bitsight Security Rating is calculated from nineteen risk vectors across four categories. Bitsight lists a few more, but those are in beta or informational and do not move the rating. This check makes three readings that between them cover six of the nineteen, and the result says so where it shows the grades rather than in a footnote:

• Email authentication — SPF domains, DKIM records and DMARC, answered by a DNS lookup.
• TLS — TLS/SSL certificates and TLS/SSL configurations, answered by a handshake.
• Web application security — answered, in part, by a homepage request.

Those six carry about a third of the rating’s weight, and they are the six that can be observed from outside without a window of history.

The thirteen it does not read:

• Botnet infections
• Spam propagation
• Malware servers
• Unsolicited communications
• Potentially exploited
• Critical vulnerability management
• Open ports
• Insecure systems
• Server software
• Desktop software
• Mobile software
• File sharing
• Security incidents

Those need an attributed estate and an observation window — which host belongs to which company, and what it was doing over months rather than at the moment of a probe. Neither is derivable from one domain by us or by anyone else, and a free tool claiming otherwise is claiming something it cannot have.

The letter grades here are this tool’s own. A Bitsight vector grade is a percentile against every company Bitsight rates, normalised for size. What these encode is printed beside each one, so the arithmetic is yours to check.

What to do with the result

Everything read here is configuration rather than architecture, which is what makes it worth clearing first. TLS and web application security are also covered by Dynamic Remediation — Bitsight’s on-demand rescan — so credit for a fix there arrives on request rather than at the next observation.

• Email authentication. Publish the transport records first, because they break nothing, and move DMARC to enforcement last, because moving it before the reports are clean is what breaks invoicing on a Monday morning. The email spoofing check gives the record to publish for each finding in that order.
• TLS. Protocol versions first — setting a minimum of TLS 1.2 on one host usually clears three findings at once. Certificates second, because each is its own reissue and they parallelise. The SSL estate check lists every affected host.
• Web application security. The port-80 redirect and HSTS first — one server setting each, and often one load balancer for every host behind it. Cookie flags second. The Content Security Policy third, because it should run report-only for a few weeks before it is enforced. Library upgrades last: each one is a regression test.
• Frontier exposures, the same day. Revoke any key found in the page, delete a dangling CNAME, and take an exploited AI tool off the internet — each is an hour’s work and none waits for a change window. Then a CAA record and a security.txt file. Post-quantum key exchange and certificate automation are projects: start them before March 2027, not after.
• Then the other thirteen. The Cyber Risk Rating Report is where they come from, with the rating itself and the benchmark against your industry. It is complimentary and needs no access to your systems.