Web Application Header Finding Considerations – Bitsight Knowledge Base

Web Application Header findings are generated with host and port data. Each Host:Port pair is considered as a single finding.

If the issues(s) identified in the finding are remediated and the site remains accessible, a new finding will be created and will replace the initial finding in the risk vector grade calculation. If the destination cannot be located when a finding is remediated, a new finding is not generated and the previous BAD finding impacts the grade until it completes its lifetime. This can happen when a web application firewall (WAF) is in place or the destination domain belongs to the WAF. Refer to Asset Not Reached for details.

To reduce the population of “noisy” observations that are not valid risk indicators, the following criteria are applied:

Item	Criteria	Why?
Hostname	The host is part of the company’s infrastructure.	Countless hosts, including subdomains (mail.google.com), are tallied. This is to detect Web Application Headers across the Bitsight inventory. The company’s domains are used as the criteria for identifying hosts. Related records are matched and assigned to a company. This handling of wildcards in DNS records prevents the creation and evaluation of repeated findings. Example: If the company has a subset domain (e.g., saperix.com) of the host specified in the record (www.saperix.com), the observation is recorded.
Port	Must be port 80 or 443.	These ports are the most likely to host content that is of interest. Non-standard ports (8000, 8080, 8443, etc.) are often web management interfaces for software and hardware platforms.
Hardware Appliances	Must not be common hardware appliances, i.e., Cisco ASA, Sonicwall firewalls, etc.	These are the devices that general users cannot address and fix.
Content-Type	Must be “text/html.”	If the Content-Type is “application/json,” this typically means the host is a HTTP-based API. Example: An image is not a useful web application. The record will be dropped.
Content-Length	Must be absent or greater than 0.	If present and is specified as “0” (no HTML returned), the record is not generated. If the header is missing from the response, this check is skipped.
Response	Must end in “200.”	The data provider normally follows all 3xx-based redirects, but if the 3xx redirect causes the protocol to change (such as from HTTP to HTTPS or vice versa), the record ends and a new record is created for the new protocol. If the response ends in anything else, such as: 3xx redirect - The headers received from the web application are not necessarily the headers that a normal user would observe. 4xx or 5xx HTTP status code - Something went wrong during the request. The ultimate resource was not returned.
Redirects	Redirects to a different hostname (i.e., saperix.io) will result in a record being created only for saperix.io, assuming saperix.io is part of the company’s infrastructure.	Records are based on the original hostname. When subdomains with different URLs are shortcuts to the same web application, the number of records may be excessive. If a record is based on the terminal hostname, it will have rapid fluctuations in record grades. This is because a different page is evaluated each day. When a subdomain of a company redirects to a domain (and infrastructure) that belongs to a different company, the company that the record should be assigned to is ambiguous.
Protocol Changes	Can only change from HTTP to HTTPS.	Redirects from HTTPS to HTTP is a misconfiguration and should be addressed.

January 9, 2023: Linked to Asset Not Reached resource.
November 15, 2019: Evidence key updated from Host:IP:Port to Host:Port. Each Host:Port pair is now considered as a single finding.
August 29, 2018: Published.

Related articles