Security Performance Management
Continuous Monitoring
Cyber Insurance
National Cybersecurity

Articles in this section

See more

Web Application Header Finding Considerations

Avatar
Ingrid
Follow
  • 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:

Item Criteria Why?
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:

  • 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.

Related articles