The Web Application Headers risk vector does content checks on the header. The data is analyzed to determine security risks posed to an organization’s application users.
See data collection methods or the criteria for classifying findings as Web Application Headers.
Risks
Correctly configured headers protects against malicious behavior, such as man-in-the-middle (MITM) and cross-site scripting (XSS) attacks, and prevents attackers from eavesdropping and capturing sensitive data, such as credentials, corporate email, and customer data.
Grading
See how the Web Application Headers risk vector is graded and how findings are graded.
| Concept | Behavior |
|---|---|
|
Duration: 60 Days |
|
|
A default risk vector grade is assigned. |
Default: This is set in the center of the grading scale for computing into security ratings. Some findings cannot be traced back to specific companies due to the use of third party systems; such as web filters and Content Delivery Networks (CDN), that are capable of redirecting and encapsulating network traffic. Some firewalls might also be detecting and blocking external data gathering tools from getting any data. |
|
Percentage (out of 70.5% in Diligence): 5% |
Remediation
Resources
Recommendations
Required headers are important for preventing communication attacks, between applications, from succeeding. Using proper Web Application Headers over the Internet ensure communications are robust against attacks that are designed to take advantage of ambiguity (communication details that are not explicitly defined). See how to evaluate your hosts for inclusion in Web Application Headers.
- Implement evaluated and required headers.
- Ensure application headers are created correctly and don’t have any misspellings (typos).
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.
Recommended Prioritization
HTTP/1.1, 1.0 and transport security (HTTPS or HTTP) are the common combinations of protocol. Starting with implementing the following configurations across your web application headers is recommended to improve BAD and WARN grades to FAIR.
- Content-Security-Policy (CSP): A properly configured CSP can help prevent XSS attacks by restricting the origins of JavaScript, CSS, and other potentially dangerous resources. For more information about this directive, refer to the W3: Content Security Policy Level 2 and Mozilla: Using Content Security Policy documentation.
- X-Content-Type-Options: Setting X-Content-Type-Options to “nosniff” prevents against MIME or content sniffing.
- Strict-Transport-Security: Required for any HTTPS configuration. Enforces the use of HTTP over TLS/SSL. Properly using this header can help prevent MITM attacks. The Strict-Transport-Security header is defined in RFC-6797.
Finding Behavior
| Concept | Behavior |
|---|---|
|
The Bitsight platform regularly checks for new observations. Bitsight findings are updated as these observations change, e.g., newly observed Diligence findings or an existing finding was remediated. |
Automated Scan Duration: 60 Days User-Requested Refresh Duration: 3 Days |
|
Remediation may generate a new finding. The new finding might not replace the previous finding.
|
Resources
- March 25, 2024: “No findings/low findings” changed to “insufficient data.”
- November 10, 2023: Linked to finding messages.
- August 16, 2023: New Grading & Finding Behavior sections.
Feedback
1 comment
Bitsight is flagging the "__cfduid" cookie set by Cloudflare as problematic because it does not contain the secure attribute. This is not something that Cloudflare clients can configure and Cloudflare has no plans to enabled the secure flag, nor does it make sense to enable the flag. From Cloudflare:
The __cfduid cookie is used to override any security restrictions based on the IP address the visitor is coming from. For example, if the visitor is in a coffee shop where there are a bunch of infected machines, but the visitor’s machine is known trusted, then the cookie can override the security setting. It does not correspond to any userid in the web application, nor does the cookie store any personally identifiable information.
Note: This cookie is strictly necessary for site security operations and can’t be turned off.
https://community.cloudflare.com/t/pci-scan-failed-cookie-does-not-contain-the-secure-attribute/1636/4
Does Bitsight have any plans to work with organizations who are using Cloudflare? It seems regressive to penalize an organization's score for using a service like Cloudflare.
Please sign in to leave a comment.