Web Application Headers Risk Vector

⇤ Diligence Risk Category

The Web Application Headers risk vector analyzes security-related fields in the header section of communications between users and an application. They contain information about the messages, determine how to receive messages, and how recipients should respond to a message.

Much like a business letterhead, headers explain where the message is going and who it’s from, date sent, what type of message it is, and other configuration options. They're included in all back-and-forth communications between applications. Web servers and web-connected applications must conform to a certain set of language (communication) standards when sending information over the Internet. These language definitions are called “protocols.”

Web Application Headers cover security risks posed to an organization's application users through Hypertext Transfer Protocols (HTTP) headers. HTTP defines the way a website should respond when it can’t find something, if it can find something, or something was temporarily moved. For example, the “404” page (page not found error) can be understood by your web browser thanks to the HTTP standard. Otherwise, web programmers might pick obscure numbers or other ways to tell you that a page is not found. Your browser will then have to guess.

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.

Remediation

Review Web Application Header findings and finding messages.

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” helps to prevent 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