Skip to main content
Version: 6.11.0

HTTP Response Header Addition

Some security vulnerabilities can be resolved when the HTTP/HTTPS response contains the appropriate headers.

Overview​

Using the HTTP Response Header Addition rule you can add custom HTTP/HTTPS Headers to the responses of web applications. For an HTTP endpoint targeted by the rule, these headers are inserted into all HTTP/HTTPS responses of Servlets, JSPs, and static resources.

The following are examples of those headers:

  • X-XSS-Protection: enables the Cross-Site Scripting filter in your browser.
  • X-Content-Type-Options: allows to opt-out of MIME type sniffing.
  • X-Frame-Options: protects against Clickjacking attacks, also known as UI redressing.
  • Strict-Transport-Security: tells browsers to enforce HTTPS protocol over HTTP.
  • Access-Control-Allow-Origin: allows web servers to specify the domains that can benefit from Cross-Origin Resource Sharing (CORS) functionality.
  • Content-Security-Policy: enables another layer of security that helps to detect and mitigate certain types of attacks, including Clickjacking, Cross-Site Scripting (XSS) and data injection attacks.

When using the HTTP Response Header Addition rule to set custom HTTP/HTTPS response headers, you are advised to check that the web browser supports the inserted HTTP/HTTPS response header. Providing this is satisfied, you are free to add any HTTP/HTTPS response header name and value. The agent will never attempt to override existing application headers.

HTTP/HTTPS response headers added by this rule may change the way the browser renders the application's web pages.

Rule Options​

HTTP Endpoint (Optional)​

Here you can enter in a list of relative URIs to be protected, monitored, or whitelisted.  A relative URI only includes the path portion of the URL, and not the domain.  For example if the website address was http://www.victim.com/home/test.html, then /home/test.html is the relative URI or HTTP Endpoint.

The path within the relative URI must be absolute and begin with a leading /. In the above example /home/test.html is valid, and home/text.html is not. In addition relative paths may not contain .. or other similar characters denoting path shortcuts. For example, /home/test/user/test.html is valid, but ../test/user/test.html is not.

Set Header Name​

This is the name of a header that the rule will be applied to.

Set Header Value​

This is the value of the aforementioned Header Name.

A Response Header Addition rule can apply to multiple headers at once. Header names and values will be stored as pairs in the table that will appear below the name and value fields once a pair has been added. At least one pair must be added to the rule or an error condition will occur. Pairs may be deleted or edited utilizing the Actions options for each row.

Action​

  • Protect - Protect is the only option available for this rule. The Waratek Agent will actively prevent the lookup of the address(es) from succeeding.

The Agent will not allow multiple HTTP Response Header Addition rules that specify the same header name.

Log Messaging​

The logs provide a message field, which can be customized.  Text entered here is the message that will be seen on the log files when the rule has been triggered, regardless of the Action.  If the field is left blank, then the default logging message will be displayed in the message portion of the event log.

Severity​

The log files allow you to select a custom severity level for the event: Low, Medium, High or Critical.  A severity is required, and there is no default selection.

Advanced Options​

Disable Logging - By checking this option, no logging will be performed when a rule is triggered. Subsequently the Portal will not see these events, and they will not appear anywhere in the Portal, nor will they be searchable in Event Storage.

Resources​

More information on HTTP Response Header Addition can be found at:

  • the CWE’s community-developed website
  • the OWASP Foundation’s websiteReferences