- 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.
Web Application Header findings are generated with host and port data. Each Host:Port pair is considered as a single finding.
If the destination cannot be located when a finding is remediated, a new finding is generated. 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:
|Hostname||The host is part of the company’s infrastructure.||
Countless hosts, including subdomains (mail.google.com), are tallied by Bitsight. 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.
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:
|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.||
|Protocol Changes||Can only change from HTTP to HTTPS.||
Redirects from HTTPS to HTTP is a misconfiguration and should be addressed.