Web Assessability

Web Assessability is the precondition check for the rest of Web Application Security. It asks one thing: can the scanner actually reach your primary host and observe its response? If the apex (and any same-zone primary hosts) returns meaningful HTML when the scanner asks for it, this check passes. If the host is down, blocked, behind an interactive bot challenge, or returns transport failures, this check fails or returns Inconclusive depending on why.

When this check fails, every other Web Application Security check that depends on probe content (Header & TLS Security, Web Presence Quality, header sub-weights) loses the ability to score against your real configuration. Fix this first.

How the check works

Per scan, RedScore identifies the set of primary web hosts (apex and same-zone hosts that are recognizable as primary) and counts how many returned a meaningful response. The score is the ratio of meaningful primaries to total primaries.

A response is meaningful if it returned actual content the scanner could parse: a real HTTP status code (not a connection failure), a body, and headers. Empty WAF challenges, transport failures, and 5xx-with-no-body responses count as inconclusive rather than meaningful.

How the verdict maps to evidence

• Pass (low): assessability_ratio at or above 0.9. Most or all primary hosts returned meaningful content.
• Warn (medium): ratio between 0.45 and 0.9. Some primaries assessable, others blocked or unreachable.
• Fail (high): ratio below 0.45, or zero meaningful primaries at all.

Evidence shows primary_hosts_total, primary_hosts_with_meaningful_artifact, primary_hosts_https_reachable, and the assessability_ratio. sample_probes contains a slice of the actual probe responses.

Special states

Not Applicable

If your apex redirects to a different domain (yourdomain.tld redirects to yourbrand.com), this check returns N/A and the redirect target's apex is scored on its own scan. Audit whether the redirect is intentional.

Inconclusive

Three flavors of inconclusive, all of which return no score (the check intentionally does not punish you for scanner-side blockers it can identify):

• No probe artifacts at all. The web probe task did not run or did not finish in time. Re-run the scan.
• Primary hosts exist but every primary returned only inconclusive edge responses (WAF block, upstream error, transport failure). The check distinguishes "controls absent" from "controls unobservable behind a blocker."
• No primary host rows but only inconclusive edge probes. Same logic.

Inconclusive is honest, not a free pass. It usually points at a real problem (WAF over-blocking, scanner-IP blocked, transient host failure) that affects real users too. Investigate even when no score deduction is applied.

Fail or warn: get the primary host meaningfully reachable

Walk the sample_probes in evidence. For each primary host, look at status, body length, and any error indicators. Common causes:

Host down or unreachable

The simplest case. The scanner could not connect at all. Causes: server crashed, container died, infrastructure outage, DNS pointing at the wrong IP. Confirm with curl -v https://yourdomain.tld from outside your network. If you cannot reach it either, the host is genuinely down.

WAF or bot-protection blocking the scanner

Cloudflare's bot fight mode, Akamai's bot manager, AWS WAF rate limits, and similar tools sometimes treat security scanners as malicious traffic and return interactive challenges, 403s, or empty responses. The scanner cannot solve interactive challenges or pass JavaScript checks.

• Cloudflare: turn off Super Bot Fight Mode for known scanner traffic, or whitelist scanner IPs in your WAF rules. Be careful: turning off bot protection broadly weakens your real defenses.
• AWS WAF: review rate-limit and bot-control rules; add an allow-list rule for known scanner IPs above the rate limits.
• Akamai, Imperva, Sucuri: similar pattern; allow-list specific scanner sources.
• Be honest about whether the WAF is also blocking real users. "Scanner gets challenge" sometimes means "any visitor on a less-common browser or VPN gets the same challenge."

TLS handshake failure

Apex resolves and the TCP connection succeeds, but the TLS handshake fails. Causes: expired cert, unsupported cipher suite, missing intermediate, hostname mismatch, requiring TLS 1.3 from a client that only negotiates TLS 1.2.

Test with openssl s_client -connect yourdomain.tld:443 -servername yourdomain.tld < /dev/null. The output shows the handshake error explicitly. Fix according to the error (renew cert, add intermediate, expand cipher list, etc.). The dedicated cert and TLS sub-weight pages cover specifics.

Geo-blocking

Some hosts intentionally block traffic from specific regions or hosting-provider ASNs. If RedScore's scanner egress sits in a blocked region, your hosts return assessability inconclusive even though real users elsewhere can reach you. There is no clean fix beyond accepting the inconclusive result or whitelisting scanner traffic.

Empty response with 200 status

Server returned a 200 but no body, or a body too small to count as meaningful. Causes: misconfigured app returning empty responses, health-check endpoint accidentally exposed at the apex, or content-type returning a non-HTML payload. Audit what the server actually returns at /.

Verify the fix

• From outside your network, run curl -sI https://yourdomain.tld and curl -sL https://yourdomain.tld | head -50. Confirm a 200 (or other expected status) and real body content.
• Test from a few different vantage points (cloud VM, mobile network, residential IP) to catch geo or IP-based blocking.
• If the host is behind a WAF, send a request with a generic User-Agent (curl/8.x or similar). If the WAF gates on user-agent fingerprinting, the response will differ from a browser request.
• Re-run the RedScore lookup. The verdict moves to pass when the assessability ratio reaches 0.9.

Common pitfalls

• Allow-listing the scanner without fixing the real problem. If your WAF blocks the scanner, it probably also blocks legitimate visitors from less-common browsers, VPNs, or screen readers. Allow-listing the scanner only buys you a passing score, not real reachability.
• Treating Inconclusive as Pass. Inconclusive means the check could not score; it does not mean everything is fine. Investigate the underlying cause (WAF block, transport failure) since real users likely hit the same wall.
• Cross-domain redirects mistakenly scored as fail. Should be N/A. If you see a fail on a host that just redirects to your real brand domain, the apex redirect detection did not fire. Verify with curl -ILs https://yourdomain.tld.
• Health-check endpoint at apex returning empty 200. If your apex serves a load balancer health check (returns "OK" or empty 200), it counts as meaningful by status but thin by content. Pair with Web Presence Quality findings; serve real content at apex.
• Same-zone hosts with restrictive firewalls. If api.yourdomain.tld is intentionally locked to internal traffic but appears in public DNS, it counts as a primary and drops your score. Either remove it from public DNS or open a narrow path that returns a meaningful response (a 401 from the API root, for example, is better than no response).