Back to the snapshotMETHOD AND LIMITS

How the website security score works

A score of observed public best practices, with coverage and practical next steps. Public configuration is one part of a broader security review.

How the score works

The instant audit has 21 planned checks, including 16 scorable checks in four areas: HTTPS & connection, website hardening, email protection, and domain & certificates. Technology families, mail routing and public DNS destination validation are context only. Public reputation and indexed exposure do not contribute to the score.

The percentage is best practices observed in place divided by checks that produced an observation. For example, 12 aligned checks among 16 observed checks give 75%. Unknown checks never count as pass or fail. Not-applicable checks are excluded from the applicable denominator. Coverage is always shown alongside the score.

An area is graded only with at least 50% of its applicable scorable checks observed. Below that it is “Not graded.” The overall score requires at least 6 observed checks and at least 2 graded areas. Otherwise, the result explains that more observations are needed.

Area grades use the unrounded aligned-to-observed ratio: A ≥90%, B ≥75%, C ≥60%, D ≥45%, otherwise F. Displayed percentages are rounded to the nearest whole number; grades are determined before rounding. The overall percentage counts all observed scorable checks, including observations in areas that do not yet qualify for a grade.

This is a best-practice completion measure, not a security rating, certification, probability of compromise or proof of compliance. Some checks recognize presence only: an advertised CSP does not establish effectiveness, and absence of optional CAA records is not treated as a defect. Read the observation and its limitations before making a change.

What we observe

The instant review covers a registered public apex and its exact www host, root / only on TCP 80/443. It uses public DNS records, ordinary credential-free HTTP and HTTPS requests and standard TLS connections. No script execution or linked-asset fetching is included.

The limits are five page requests including redirects, a 90-second total collection deadline, eight seconds per request and two redirect hops. Responses are limited to 256 KiB each and 1 MiB in aggregate, with at most 24 DNS queries and five standard TLS connections. There can be two concurrent requests, one per host. These are maximums, not a guarantee every check will finish.

HTTPS, redirects, TLS authentication and HSTS are separate observations. TLS uses one standard TLS 1.2-or-newer client handshake; older protocols, cipher suites, revocation and alternate chains are not probed. A failed authenticated connection does not provide accepted certificate dates.

SPF presence does not validate syntax, include chains, lookup limits or real senders. DMARC recognition does not validate real-message alignment, reporting or receiving-server handling. DKIM stays unknown without legitimate selector evidence; selectors are not guessed. CAA interpretation does not establish complete issuance semantics or inheritance.

Browser headers, cookie attributes, explicit HTTP references, technology families and exposed versions come from the same cached root response. A usable application sample is required for relevant checks. Challenge pages, incomplete bodies and unavailable sources can leave questions unknown. No raw HTML or cookie names and values are included in the report.

Checks in the instant review

  • SPF record
  • DMARC policy
  • Mail routing records
  • Certificate authority policy
  • DKIM signing
  • HTTPS connection
  • HTTP-to-HTTPS redirect
  • Authenticated TLS handshake
  • Certificate expiry
  • HTTPS Strict Transport Security
  • Content Security Policy
  • Framing restrictions
  • Content-type sniffing restriction
  • Referrer policy
  • Cookie attributes
  • HTTP resource references in HTTPS HTML
  • Public technology signals
  • Public version disclosure
  • Public DNS destination validation
  • Public reputation datasets
  • Indexed external exposure

Coverage and evidence

Each usable observation includes its source, retrieval time, observation time where known, confidence and limitations. Unknown, unavailable and not applicable have distinct meanings. A normally completed run can contain unknown checks; a partial run indicates interruption, an error or a collection limit.

Progress reflects saved work, not an estimated animation. Reading a result does not start collection again. Examples use clearly labeled invented observations and do not establish findings for any real domain.

Missing evidence is not proof that a control failed or that a system is safe. A technology family or exposed version does not establish patch status, vulnerability applicability or exploitability.

What needs a separate review

Other paths, subdomains, ports and authenticated surfaces are outside the instant scope. We do not attempt logins, submit forms, inspect private services or perform exploitation. Domain confirmation does not authorize additional testing.

Public configuration cannot establish MFA effectiveness, access governance, endpoint coverage, backup recovery, internal segmentation, incident readiness, compliance or the presence or absence of compromise. These questions need internal evidence and an agreed assessment.

Suggested owners are roles to consult. Validate business context, test changes and agree an order of work with the responsible administrator.

Continue with a useful scope

The free expanded external review adds a separately agreed public inventory and IT-ready remediation pack. Paid diligence, internal assessment and any active testing need their own written scope, methods and evidence-handling arrangements.

Read the practical security guides or start with your domain.