How WebShield scores website security

Every grade WebShield gives is meant to be checkable. This page documents exactly how the number is produced, and it is rendered from the same constants the scanner runs on, so the rubric here cannot drift from the code.

The model

A scan is split into five weighted categories. Each category starts at 100 points and loses points for each problem found, floored at zero. The five category scores are combined by their weights into a single score from 0 to 100, which maps to a letter grade. Serious failures also apply a grade cap that holds the letter down no matter how high the numeric score is. A check we could not run (for example, a TLS probe that the server refused) is marked as not checked and never lowers the grade.

Category weights

Grade scale

Grade caps

Any of these holds the grade to no better than the letter shown, regardless of the numeric score. A site with an otherwise clean configuration but one of these problems is still capped.

What we do NOT check

A grade here is a configuration and posture audit of public responses. It is not a guarantee that a site is secure. We deliberately do not do:

• Malware, phishing, or blocklist reputation.
• Active exploitation (SQL injection, XSS fuzzing, or any intrusive probing).
• Subdomain discovery or enumeration.
• The full TLS vulnerability battery (Heartbleed, ROBOT, and similar) that SSL Labs covers.
• Anything behind authentication.

Some checks are best-effort by nature, and we say so in the report: DKIM presence is inferred from a list of common selectors, DNSSEC uses a resolver's authenticated-data flag rather than full chain validation, and because we do not run a headless browser, scripts injected at runtime by single-page apps are not executed or seen.

Keep going