Web Application Header Finding Grades – Bitsight Knowledge Base

⇤ Methodology

Web Application Header findings are evaluated and are then assigned a finding grade. Refer to finding considerations to see how Web Application Header findings are generated.

Content Checks
Finding Weights
Finding Grades
- GOOD
- FAIR
- WARN
- BAD
- NEUTRAL

Content Checks

The entire header configuration (not individual errors) is analyzed. General security practices and header security are the main classes of findings.

Content Check		Methodology
Content-Security-Policy is missing.		For just the headers, any missing Content-Security-Policy is penalized.
Intra-site URLs.		Intra-site URLs are evaluated for HTTPS protocol use.
Insecure authentication; Log in from an http page.		We check if the `WWW-Authenticate` is contained in an HTTP 401 response from non-HTTPS events.
Insecure redirects:
	There's an HTTPS to HTTP redirect. It is changed to be an HTTPS to HTTPS redirect.	HTTPS to HTTPS redirects are graded as NEUTRAL. Since NEUTRAL Web Application Header findings do not impact the risk vector grade, they do not replace the HTTPS to HTTP redirect BAD finding grade.
	There’s an HTTP request in a redirect chain.	Once there has been any HTTP request in a redirect chain, the security of the chain is potentially compromised. For example, an attacker can intercept the HTTP request (man-in-the-middle) and then redirect the destination. Even having the final URL requested via HTTPS doesn’t protect against this.^[1] ^[2] ^[3]
	Redirects to a deep link of a hostname.	Redirects to a deep link of a hostname are graded on the contents of that particular page. Example: The following redirect is considered to be targeting the same hostname and to a deep link of that same hostname: example.com redirects to example.com/app/settings
A required header is not present.		The company is penalized on missing required headers, as described in the configuration requirements.
Optional headers are present.		Optional headers are verified that they are configured correctly and go towards the requirements as a whole for a GOOD or FAIR finding grade, as described in the configuration requirements.
Optional headers are not present.		Since optional headers are unnecessary for preventing malicious actions (as described in the configuration requirements), there’s no penalty.
`Set-Cookie` header is not set.		HTTP findings are not graded unless the `Set-Cookie` header is set.
Mixed content (HTTP and HTTPS).		HTTP is not secure. Learn why HTTPS is preferred over HTTP: National Cyber Security Centre: Serve websites over HTTPS (always) Troy Hunt: Here's Why Your Static Website Needs HTTPS If `upgrade-insecure-requests` is specified in the `Content-Security-Policy` header, any check for the presence of mixed content is skipped and there’s no penalty.
An HTTP Strict-Transport-Security (HSTS) header on an HTTP response.		An HTTP Strict-Transport-Security (HSTS) header on an HTTP response is ignored.
Wildcard DNS		The presence of wildcards in DNS records can have an unnecessary magnification of the number of Web Application Header findings. These repeated findings are handled as a single finding.

Finding Weights

Findings are relatively weighted.

Required headers have the same weight.
The individual weights for findings depend on their issues.

Example: A missing required header or a completely incorrect header is weighted heavily.

Type	Weight
Insecure redirects.	Heavy
Insecure authentication. Logged in within an http page. `WWW-Authenticate` (Error #401)	Medium
Mixed content.	Medium
HTTP Header	Light

Finding Grades

GOOD

Findings with perfect headers (HTTPS connections are present and Set-Cookie is secure) are graded as GOOD.

FAIR

Findings with imperfect headers are graded as FAIR. FAIR Web Application Header findings have a negative impact on the rating.

WARN

Web Application Header findings are graded WARN if at least one required header is set, properly formatted, and contains a secure configuration, but other required headers are missing.

BAD

Web Application Header findings are graded BAD if:

Any HTTP links or references embedded in an HTTPS website is present. See content checks.
One or more of the heavy and medium weighted findings are present. If none are present, it is graded based on the average weight of the observed headers.
There are any requests for credentials that use the WWW-Authenticate header.
Hyperlinks in the HTML for the web page downgrade the user inside the site and the domain of the site and ensure the HTML of the webpage does not import resources (such as scripts and images) from outside the site using HTTP instead of HTTPS.
There are HTTPS findings that immediately downgrades the user to an HTTP connection using a redirect.
None of the required headers are set.

NEUTRAL

NEUTRAL Web Application Header findings do not negatively impact the risk vector grade.

No headers are graded unless Set-Cookie is defined. If not defined, the grade defaults to NEUTRAL.
For HTTP connections, no headers are graded unless Set-Cookie is defined. If not defined, the grade defaults to NEUTRAL.
Redirects to a different hostname with a different IP address are graded as NEUTRAL.

Redirects to a deep link of a hostname are graded on the contents of the destination landing page.
Remediated findings are graded as NEUTRAL, which replaces the previous BAD finding. Remediation may generate a new finding that does not replace the previous finding. Refer to finding considerations to see how Web Application Header findings are generated.

Resources

August 16, 2024: FAIR and WARN.
January 9, 2023: Linked to finding consideration resource.
October 20, 2021: Ratings Algorithm Update 2021.