Methodology

What a scan does

A scan runs a fixed set of independent checker modules against the target URL. Before those modules run, the scanner follows the target's full redirect chain (so every module inspects the address a visitor actually lands on, not the first URL entered), and revalidates every hop along the way. The modules that run against the resolved target are:

• SSL/TLS
• HTTP security headers
• Redirect behavior
• Cookie attributes
• DNS configuration
• Technology detection (informational)

Each module runs independently and is time-bounded. If a module fails or times out against a particular target, that failure is logged and the scan continues with the remaining modules — a module that could not complete is not treated as a passing (or failing) result for that category. See "What ‘Not measured’ means" below.

Categories checked and their weight

Every finding belongs to a category. Each category has a maximum number of points it can cost the overall score, regardless of how many individual findings land in it. The weights below sum to 100 and reflect the categories' relative security impact, as encoded directly in the scoring engine:

Any category outside this fixed list falls back to a default cap of 10 points.

Severity model

Every individual finding is assigned one of five severity levels, and each severity carries a fixed point deduction:

How the score is calculated

The calculation is a fixed arithmetic rule, run the same way for every scan:

1. Start from a base score of 100.
2. For every finding, add its severity's fixed point deduction to a running total for that finding's category.
3. For each category, cap that category's total deduction at the category's maximum (the table above). A category cannot cost the score more than its cap, no matter how many findings it produced.
4. Subtract the sum of all capped category deductions from 100. The result is clamped between 0 and 100.

This means the score is driven entirely by how many findings exist, in which categories, and at what severity — nothing about traffic, reputation, industry, or history factors into it.

Why fixing an issue can leave the score unchanged

Because deductions are capped per category, a category that produces many findings (headers checks several distinct headers, for example) can rack up more raw deduction than its cap allows. When that happens, the score already reflects the cap, not the raw total — so resolving one issue in an over-the-cap category can leave the score exactly where it was, because the cap was already absorbing the difference. The score only moves once the category's raw deduction drops back under its cap. This is a known, deliberate property of the capping design, not a bug — it keeps one noisy category from single-handedly sinking a score that is otherwise clean.

Grade thresholds

The final score maps to a letter grade using fixed thresholds:

What "Not measured" means

If a check could not be completed against a target — a module timed out, or failed for a reason specific to that target — it is not scored as if it had passed, and it is never rendered as a zero or a default value standing in for a real result. It is labelled "Not measured" instead, so a scan report never implies certainty the scan does not actually have. This is the same convention already used across Nivaronix's reporting: a value the platform did not observe is always disclosed as unmeasured, never guessed or defaulted.

Scan scope and limitations

• A scan describes the target at the moment it ran. It is a point-in-time snapshot, not a continuous measurement — a site's configuration can change at any time after a scan completes.
• The scanner checks external, observable configuration (SSL/TLS, HTTP headers, redirects, cookies, DNS, and detectable technologies). It does not test application logic, authenticate into the target, attempt exploitation, or perform any form of penetration testing.
• A finding's absence means the check ran and found no issue at that severity — it does not mean the target has no security issues outside what this scanner is built to check for.
• Each scan is bounded by a fixed timeout. A target that is slow or unreachable within that window produces "Not measured" results for the affected checks rather than a false pass or fail.

Evidence and reports

Findings and scores shown in a Nivaronix report are reproduced directly from the stored scan record — nothing in a report is estimated, extrapolated, or filled in with a default value. Where evidence is available (for example the hops of a followed redirect chain), it is attached to the relevant finding so a result can be independently verified rather than taken on faith.

Continuous monitoring

Beyond a one-off scan, Nivaronix can re-run these same checks against a monitored asset on a recurring schedule and raise an incident when a check's result changes for the worse. The scoring rule applied on each run is identical to the one described on this page — monitoring does not use a different or weighted methodology from a manual scan.

Frequently asked questions

Related pages

• What is a website security score? — what the score means and how grades map to it.
• How is a website security score calculated? — a shorter, search-focused guide.
• Run a free website security scan