Configuring an HTTP Header Security policy

HTTP response security headers are a set of standard HTTP response headers proposed to prevent or mitigate known XSS, clickjacking, and MIME sniffing security vulnerabilities. These response headers define security policies to client browsers so that the browsers avoid exposure to known vulnerabilities when handling requests.

When the HTTP Security Headers feature is enabled, headers with specified values are inserted into HTTP responses coming from the backend web servers. This is a quick and simple solution to address the security vulnerabilities on user's website without code and configuration changes.

To configure an HTTP Header Security policy:

1. Go to Web Application Firewall > Sensitive Data Protection.
2. Click the HTTP Header Security tab.
3. Click Create New to display the configuration editor.
   
4. Configure the following HTTP Header Security settings:
   

   Setting	Description
   Name	Enter a unique HTTP Header Security policy name. Valid characters are A-Z, a-z, 0-9, _, and -. No space is allowed. Note: Once saved, the name of an HTTP Header Security policy cannot be changed.
   Request Status	Enable/disable request URL match. This is disabled by default. Enable — Responses to the request will be processed with the security headers only if the URL of a request matches the specified request URL. Disable — All responses will be processed with the selected security header(s).
   Request URL	The Request URL option is available if Request Status is enabled. Specify the URL used to match requests so that security headers can be applied to responses of the matched requests.
   Mode	Specify header operation mode for the response from the back-end server(s). Add-Always — always add the specified header(s). Add-Replace —add the specified header(s) if not exist, replace the value of header(s) which exist already. Add-If-Absent — only add the specified header(s) if not exist, do nothing if the same header(s) exist The default option is Add-Always.

5. Click Save.
   Once the HTTP Header Security configuration is saved, the HTTP Header Security Rules section becomes available to configure.
6. Under the HTTP Header Security Rules section, click Create New to display the configuration editor.
   
7. Configure the following HTTP Header Security Rules settings:
   

   Setting	Description
   Name	Select the HTTP security header name from the drop-down menu. content-security-policy x-content-type-options x-frame-options x-xss-protection http-strict-transport-security
   Policy	The Policy option is available if the Name is content-security-policy. Enter the header value(s) that setting restrictions on resource types and sources. For example, default-src 'self';script-src 'self';object-src 'self'.
   Report Only	The Report Only option is available if the Name is content-security-policy. Enabling report-only switches to “Content-Security-Policy-Report-Only” header, which accepts all directives of CSP. However, “report-only” header only monitors the violations. FortiADC will check the existing of “report-uri” directive once “report-only” selected.
   Max-age	The time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS. A max-age value of zero (i.e., “max-age=0”) signals the UA cease regarding the host as a Known HSTS Host, including the includeSubDomains directive (if asserted for that HSTS Host).
   Include Subdomain	Optional. If enabled, rule will apply to all of the site's subdomains as well.
   Preload	Google maintains an HSTS preload service: https://hstspreload.org/. By following the guidelines and successfully submitting your domain, browsers will never connect to your domain using an insecure connection. While the service is hosted by Google, all browsers have stated an intent to use (or actually started using) the preload list. Most major browsers (Chrome, Firefox, Opera, Safari, IE 11 and Edge) also have HSTS preload lists based on the Chrome list. (See the HSTS compatibility matrix.) However, it is not part of the HSTS specification and should not be treated as official.

8. Click Save.
   Once the HTTP Header Security Rules configuration is saved, the editor dialog closes.
9. Click Save to update the HTTP Header Security configuration.
   Once the HTTP Header Security policy is saved, you can reference it in a WAF Profile.

HTTP Security Header Names

Security Header	Description
Content Security Policy	A Content Security Policy (CSP), is an additional layer of security delivered via an HTTP header. This policy helps prevent attacks such as Cross Site Scripting (XSS) and other code injection attacks by defining content sources which are approved thus allowing the browser to load them. Without a CSP, the browser simply loads all files on a page without considering the source which could be harmful. This puts both the site and it’s visitors at risk of malicious activity. There are multiple directives available to website owners who want to implement a content security policy. A server may also define multiple directives within a CSP security header. For a detailed list of examples and references, visit content-security-policy.com. Additionally, you can use a tool called cspisawesome.com to easily create a CSP specific to your needs. FortiADC also provides a “report-only” flag to switch to “Content-Security-Policy-Report-Only” header, which accepts all directives of CSP, but the difference is that “report-only” header only monitor the violations. FortiADC will check the existing of “report-uri” directive once “report-only” selected.
X Content Type options	The X Content Type Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in the Content-Type headers should not be changed and be followed. This helps reduce the danger of drive-by downloads and helps treat the content the proper way. There is only one directive that can be used, which is nosniff. An example of the header looks like: x-content-type-options: nosniff
X Frame Options	The X Frame Options header provides clickjacking protection by not allowing iframes to load on your website. It is supported by IE 8+, Chrome 4.1+, Firefox 3.6.9+, Opera 10.5+, Safari 4+. There are three directives available for this header: deny, sameorigin and allow-from. But “allow-from” is obsolete and no longer works in modern browers, FortiADC will notsupport it. On FortiADC, there are two directive options: deny and sameorigin. Once “deny” selected, the header looks like: x-frame-options: DENY Once “sameorigin” selected, the header looks like: x-frame-options: SAMEORIGIN
X XSS protection	The X XSS Protection header is designed to enable the cross-site scripting (XSS) filter built into modern web browsers. This is usually enabled by default, but using it will enforce it. Although these protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline'), they can still provide protections for users of older web browsers that don't yet support CSP. On FortiADC, this function has two modes to be choose: sanitizing-mode and block-mode. Once sanitizing-mode selected (usually default in browsers), an example looks like: x-xss-protection: 1 Once block-mode selected, an example looks like: x-xss-protection: 1; mode=block
HTTP strict transport security	The HTTP strict-transport-security (HSTS) header is a security enhancement that restricts web browsers to access web servers solely over HTTPS. This ensures the connection cannot be establish through an insecure HTTP connection, would helps to protect websites against protocol downgrade attacks and cookie hijacking. There are three directives for this header: max-age=<expire-time> includeSubDomains preload An example looks like: strict-transport-security: max-age=31536000; includeSubDomains; preload