Fortinet white logo
Fortinet white logo

Administration Guide

HTTP Security Headers

HTTP Security Headers

HTTP response security headers are a standardized set of directives that instruct the browser to enforce security policies designed to prevent common client-side vulnerabilities—such as cross-site scripting (XSS), clickjacking, and MIME-type confusion. These headers define how the browser should handle scripts, resources, and frames, reducing exposure to exploits even when the application code itself does not implement strict controls.

As part of FortiWeb’s Client Side Security module, the HTTP Security Headers feature represents the first layer in a multi-stage defense strategy. By inserting security headers such as Content-Security-Policy, X-Frame-Options, and X-Content-Type-Options into HTTP responses, FortiWeb helps ensure that browser behavior is tightly regulated—blocking risky operations and enforcing origin-level trust boundaries.

When this feature is enabled, FortiWeb automatically inserts the configured headers into all HTTP responses passing through the system, without requiring changes to backend code or server configuration. This provides a scalable and centralized method to enforce browser-side protection across your application environment.

The following includes the security headers that FortiWeb can insert into responses:

FortiWeb security headers
X-Frame-Options

This header prevents browsers from Clickjacking attacks by providing appropriate restrictions on displaying pages in frames.

The X-Frame-Options header can be implemented with one of the following options:

  • DENY: The browser will not allow any frame to be displayed.
  • SAMEORIGIN: The browser will not allow a frame to be displayed unless the page of the frame originated from the same site.
  • ALLOW-FROM: The browser will not allow a frame to be displayed unless the page of the frame originated from the specified domain.
X-Content-Type-Options

This header prevents browsers from MIME content-sniffing attacks by disabling the browser's MIME sniffing function.

The X-Content-Type-Options header can be implemented with one option:

  • nosniff: The browser will not guess any content type that is not explicitly specified when downloading extensions.
X-XSS-Protection

This header enables a browser's built-in Cross-site scripting (XSS) protection.

The X-XSS-Protection header can be implemented with one of the following options:

  • Sanitizing Mode: The browser will sanitize the malicious scripts when a XSS attack is detected.
  • Block Mode: The browser will block the page when a XSS attack is detected.
Content-Security-Policy

FortiWeb adds the Content-Security-Policy HTTP header to a web page, allowing you to specify restrictions on resource types and sources. This prevents certain types of attacks, including XSS and data injection attacks.

Feature-Policy/Permission Policy

Provide a mechanism to allow and deny the use of browser features in its own frame, and in content within any <iframe> elements in the document.

For example, fullscreen 'self' https://game.com

https://map.example.com;geolocation *; camera 'none'

Referrer-Policy

Referrer-Policy HTTP header controls how much referrer information (sent via the Referer header) should be included with requests.

The value of Referrer-Policy can be "no-referrer", "no-referrer-when-downgrade", "same-origin", "origin", "strict-origin", "origin-when-cross-origin", "strict-origin-when-cross-origin", or "unsafe-url".

Cross-Origin-Resource-Policy (CORP)

Prevents other origins from loading your resources by enforcing same-origin rules for resource access.

The Cross-Origin-Resource-Policy header can be configured with one of the following values:

  • same-origin: Only allows the same origin to access the resource.

  • cross-origin: Allows all origins to access the resource.

  • same-site: Allows access from the same site (origin and subdomains).

Use in conjunction with CORS Protection for more granular control.

Cross-Origin-Embedder-Policy (COEP)

Requires cross-origin resources embedded in the page (such as scripts, styles, and images) to explicitly grant permission via CORS or CORP headers.

The Cross-Origin-Embedder-Policy header can be configured with:

  • require-corp: Embedded resources must send either a valid CORS header or a matching Cross-Origin-Resource-Policy.

This setting is required for enabling high-privilege APIs like SharedArrayBuffer.

Cross-Origin-Opener-Policy (COOP)

Isolates your browsing context from cross-origin popups or tabs to prevent side-channel attacks.

The Cross-Origin-Opener-Policy header can be configured with:

  • same-origin: Ensures that the opened window does not retain access to window.opener, blocking cross-origin interference.

Improves security for applications dealing with sensitive data or embedded login flows.

Clear-Site-Data

Instructs the browser to clear local storage, cookies, cache, and other site data when triggered (e.g., on logout).

The Clear-Site-Data header can be configured with:

  • "cookies": Deletes all cookies for the origin.

  • "storage": Clears localStorage, sessionStorage, IndexedDB, and service workers.

  • "cache": Clears HTTP cache.

  • "*": Clears all of the above.

Improves session cleanup and prevents residual data exposure on shared devices.

Timing-Allow-Origin

Controls which origins can access high-resolution performance timing data (e.g., via the Performance API).

The Timing-Allow-Origin header can be configured with:

  • Specific origin (e.g., https://www.example.com): Only allow performance timing data to be accessed by that origin.

Prevents side-channel attacks that infer cache state or user behavior by measuring load times.

Content-Security-Policy-Report-Only

FortiWeb adds the Content-Security-Policy-Report-Only HTTP header to monitor content security policy violations without enforcing restrictions. Use this header to test and fine-tune policy settings by collecting violation reports from the browser.

To configure an HTTP header security policy
  1. Go to Web Protection > Client Side Security > HTTP Header Security and select an existing policy or create a new one. If creating a new policy, the maximum length of the name is 63 characters; special characters are prohibited.
  2. If you created a new policy, click OK to save it. If editing an existing policy, select it and click Edit.
  3. Select an existing rule to edit or create a new one in Secure Header Table.
  4. Configure these settings:
  5. URL Filter

    Click to enable or disable URL filter:

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

    Select Simple String to match the URL of requests with a literal URL specified in Request URL.

    Select Regular Expression to match the URL of requests with a regular expression specified in Request URL.

    Note: this is available only when URL Filter is enabled.

    Request URL

    Specify the URL used to match requests so that security headers can be applied to responses of the matched requests.

    if Simple String is selected in Request URL Type, enter a literal URL, such as /folder1/index.htm that the HTTP request must contain in order to match the rule, or use wildcards to match multiple URLs, such as /folder1/* or /folder1/*/index.htm. The URL must begin with a slash ( / ).

    If Regular Expression is selected, enter a regular expression.

    After filling in the field with a regular expression, it is possible to fine-tune the expression in a Regular Expression Validator by clicking the >> button on the side. For details, see Regular expression syntax.

    Note: this is available only when URL Filter is enabled.

    Secure Header Type

    Select the security header to be inserted into the responses.

    • X-Frame-Options
    • X-Content-Type-Options
    • X-XSS-Protection
    • Content-Security-Policy
    • Feature-Policy/Permission Policy
    • Referrer-Policy

    For details, see FortiWeb security headers.

    Note: Since 7.4.1, The feature-policy is updated to permission-policy in alignment with the industry standard. You can click the Upgrade button to upgrade to permission-policy, then click Validate to check syntax errors that are introduced by the upgrade if any.

    Header Value

    Specify the value for the selected security header.

    If you want to match multiple values, the best practice is to list them on a single line, separated by semicolons ";" rather than setting up individual rules for each value.

    If X-Frame-Options is selected, the options will be:

    • DENY
    • SAMEORIGIN
    • ALLOW-FROM

    If X-Content-Type-Options is selected, the option will be:

    • nosniff

    If X-XSS-Protection is selected, the options will be:

    • Sanitizing Mode
    • Block Mode

    If Content-Security-Policy is selected, enter the header value(s) that your server will specify to set restrictions on resource types and sources. For example, you could enter default-src 'self';script-src 'self';object-src 'self'.

    Allowed From URL

    It will require you to specify a URI (Uniform Resource Identifier) if header X-Frame-Options and the option ALLOW-FROM are selected.

    For details, see FortiWeb security headers.

    Exception

    Select an Exception to exclude certain client or request URL from the HTTP header security policy. See "To configure an HTTP header security exception".

  6. Click OK to save the configuration.
  7. To use this HTTP Header Security policy in a protection profile, go to Policy > Web Protection Profile and configure an inline protection profile with the HTTP Header Security policy. For details, see HTTP Header Security.
To configure an HTTP header security exception

If you want to exclude certain client or request URL from the HTTP header security policy, you can add an exception rule.

  1. Go to Web Protection > Client Side Security > HTTP Header Security and select the HTTP Header Security Policy Exception.
  2. Click Create New.
  3. Enter a name for the Exception.
  4. Click OK.
  5. Click Create New.
  6. Configure the following settings.

    Client IP

    Enable to exclude HTTP header security policy based on Client IP address.

    IPv4/IPv6/IP Range

    Specify the client IP address or IP range that FortiWeb uses to determine whether or not to insert security headers to the responses.

    Request URL Type

    Select whether the Request URL field must contain either:

    • Simple String—The field is a string that the request URL must match exactly.

    • Regular Expression—The field is a regular expression that defines a set of matching URLs.

    Request URL

    Depending on your selection in Type, enter either:

    • Simple String—The literal URL, such as /index.php, that the HTTP request must contain in order to match the input rule. The URL must begin with a backslash ( / ).

    • Regular Expression—A regular expression, such as ^/*.php, matching the URLs to which the rule should apply. The pattern does not require a slash ( / ), but it must match URLs that begin with a slash, such as /index.cfm.

    Do not include the domain name, such as www.example.com, which is configured separately in Host.

  7. Click OK.
  8. Reference the Exception in an HTTP Header Security Policy.

Related Videos

sidebar video

FortiWeb: HTTP Header Security

  • 117 views
  • 7 months ago

HTTP Security Headers

HTTP Security Headers

HTTP response security headers are a standardized set of directives that instruct the browser to enforce security policies designed to prevent common client-side vulnerabilities—such as cross-site scripting (XSS), clickjacking, and MIME-type confusion. These headers define how the browser should handle scripts, resources, and frames, reducing exposure to exploits even when the application code itself does not implement strict controls.

As part of FortiWeb’s Client Side Security module, the HTTP Security Headers feature represents the first layer in a multi-stage defense strategy. By inserting security headers such as Content-Security-Policy, X-Frame-Options, and X-Content-Type-Options into HTTP responses, FortiWeb helps ensure that browser behavior is tightly regulated—blocking risky operations and enforcing origin-level trust boundaries.

When this feature is enabled, FortiWeb automatically inserts the configured headers into all HTTP responses passing through the system, without requiring changes to backend code or server configuration. This provides a scalable and centralized method to enforce browser-side protection across your application environment.

The following includes the security headers that FortiWeb can insert into responses:

FortiWeb security headers
X-Frame-Options

This header prevents browsers from Clickjacking attacks by providing appropriate restrictions on displaying pages in frames.

The X-Frame-Options header can be implemented with one of the following options:

  • DENY: The browser will not allow any frame to be displayed.
  • SAMEORIGIN: The browser will not allow a frame to be displayed unless the page of the frame originated from the same site.
  • ALLOW-FROM: The browser will not allow a frame to be displayed unless the page of the frame originated from the specified domain.
X-Content-Type-Options

This header prevents browsers from MIME content-sniffing attacks by disabling the browser's MIME sniffing function.

The X-Content-Type-Options header can be implemented with one option:

  • nosniff: The browser will not guess any content type that is not explicitly specified when downloading extensions.
X-XSS-Protection

This header enables a browser's built-in Cross-site scripting (XSS) protection.

The X-XSS-Protection header can be implemented with one of the following options:

  • Sanitizing Mode: The browser will sanitize the malicious scripts when a XSS attack is detected.
  • Block Mode: The browser will block the page when a XSS attack is detected.
Content-Security-Policy

FortiWeb adds the Content-Security-Policy HTTP header to a web page, allowing you to specify restrictions on resource types and sources. This prevents certain types of attacks, including XSS and data injection attacks.

Feature-Policy/Permission Policy

Provide a mechanism to allow and deny the use of browser features in its own frame, and in content within any <iframe> elements in the document.

For example, fullscreen 'self' https://game.com

https://map.example.com;geolocation *; camera 'none'

Referrer-Policy

Referrer-Policy HTTP header controls how much referrer information (sent via the Referer header) should be included with requests.

The value of Referrer-Policy can be "no-referrer", "no-referrer-when-downgrade", "same-origin", "origin", "strict-origin", "origin-when-cross-origin", "strict-origin-when-cross-origin", or "unsafe-url".

Cross-Origin-Resource-Policy (CORP)

Prevents other origins from loading your resources by enforcing same-origin rules for resource access.

The Cross-Origin-Resource-Policy header can be configured with one of the following values:

  • same-origin: Only allows the same origin to access the resource.

  • cross-origin: Allows all origins to access the resource.

  • same-site: Allows access from the same site (origin and subdomains).

Use in conjunction with CORS Protection for more granular control.

Cross-Origin-Embedder-Policy (COEP)

Requires cross-origin resources embedded in the page (such as scripts, styles, and images) to explicitly grant permission via CORS or CORP headers.

The Cross-Origin-Embedder-Policy header can be configured with:

  • require-corp: Embedded resources must send either a valid CORS header or a matching Cross-Origin-Resource-Policy.

This setting is required for enabling high-privilege APIs like SharedArrayBuffer.

Cross-Origin-Opener-Policy (COOP)

Isolates your browsing context from cross-origin popups or tabs to prevent side-channel attacks.

The Cross-Origin-Opener-Policy header can be configured with:

  • same-origin: Ensures that the opened window does not retain access to window.opener, blocking cross-origin interference.

Improves security for applications dealing with sensitive data or embedded login flows.

Clear-Site-Data

Instructs the browser to clear local storage, cookies, cache, and other site data when triggered (e.g., on logout).

The Clear-Site-Data header can be configured with:

  • "cookies": Deletes all cookies for the origin.

  • "storage": Clears localStorage, sessionStorage, IndexedDB, and service workers.

  • "cache": Clears HTTP cache.

  • "*": Clears all of the above.

Improves session cleanup and prevents residual data exposure on shared devices.

Timing-Allow-Origin

Controls which origins can access high-resolution performance timing data (e.g., via the Performance API).

The Timing-Allow-Origin header can be configured with:

  • Specific origin (e.g., https://www.example.com): Only allow performance timing data to be accessed by that origin.

Prevents side-channel attacks that infer cache state or user behavior by measuring load times.

Content-Security-Policy-Report-Only

FortiWeb adds the Content-Security-Policy-Report-Only HTTP header to monitor content security policy violations without enforcing restrictions. Use this header to test and fine-tune policy settings by collecting violation reports from the browser.

To configure an HTTP header security policy
  1. Go to Web Protection > Client Side Security > HTTP Header Security and select an existing policy or create a new one. If creating a new policy, the maximum length of the name is 63 characters; special characters are prohibited.
  2. If you created a new policy, click OK to save it. If editing an existing policy, select it and click Edit.
  3. Select an existing rule to edit or create a new one in Secure Header Table.
  4. Configure these settings:
  5. URL Filter

    Click to enable or disable URL filter:

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

    Select Simple String to match the URL of requests with a literal URL specified in Request URL.

    Select Regular Expression to match the URL of requests with a regular expression specified in Request URL.

    Note: this is available only when URL Filter is enabled.

    Request URL

    Specify the URL used to match requests so that security headers can be applied to responses of the matched requests.

    if Simple String is selected in Request URL Type, enter a literal URL, such as /folder1/index.htm that the HTTP request must contain in order to match the rule, or use wildcards to match multiple URLs, such as /folder1/* or /folder1/*/index.htm. The URL must begin with a slash ( / ).

    If Regular Expression is selected, enter a regular expression.

    After filling in the field with a regular expression, it is possible to fine-tune the expression in a Regular Expression Validator by clicking the >> button on the side. For details, see Regular expression syntax.

    Note: this is available only when URL Filter is enabled.

    Secure Header Type

    Select the security header to be inserted into the responses.

    • X-Frame-Options
    • X-Content-Type-Options
    • X-XSS-Protection
    • Content-Security-Policy
    • Feature-Policy/Permission Policy
    • Referrer-Policy

    For details, see FortiWeb security headers.

    Note: Since 7.4.1, The feature-policy is updated to permission-policy in alignment with the industry standard. You can click the Upgrade button to upgrade to permission-policy, then click Validate to check syntax errors that are introduced by the upgrade if any.

    Header Value

    Specify the value for the selected security header.

    If you want to match multiple values, the best practice is to list them on a single line, separated by semicolons ";" rather than setting up individual rules for each value.

    If X-Frame-Options is selected, the options will be:

    • DENY
    • SAMEORIGIN
    • ALLOW-FROM

    If X-Content-Type-Options is selected, the option will be:

    • nosniff

    If X-XSS-Protection is selected, the options will be:

    • Sanitizing Mode
    • Block Mode

    If Content-Security-Policy is selected, enter the header value(s) that your server will specify to set restrictions on resource types and sources. For example, you could enter default-src 'self';script-src 'self';object-src 'self'.

    Allowed From URL

    It will require you to specify a URI (Uniform Resource Identifier) if header X-Frame-Options and the option ALLOW-FROM are selected.

    For details, see FortiWeb security headers.

    Exception

    Select an Exception to exclude certain client or request URL from the HTTP header security policy. See "To configure an HTTP header security exception".

  6. Click OK to save the configuration.
  7. To use this HTTP Header Security policy in a protection profile, go to Policy > Web Protection Profile and configure an inline protection profile with the HTTP Header Security policy. For details, see HTTP Header Security.
To configure an HTTP header security exception

If you want to exclude certain client or request URL from the HTTP header security policy, you can add an exception rule.

  1. Go to Web Protection > Client Side Security > HTTP Header Security and select the HTTP Header Security Policy Exception.
  2. Click Create New.
  3. Enter a name for the Exception.
  4. Click OK.
  5. Click Create New.
  6. Configure the following settings.

    Client IP

    Enable to exclude HTTP header security policy based on Client IP address.

    IPv4/IPv6/IP Range

    Specify the client IP address or IP range that FortiWeb uses to determine whether or not to insert security headers to the responses.

    Request URL Type

    Select whether the Request URL field must contain either:

    • Simple String—The field is a string that the request URL must match exactly.

    • Regular Expression—The field is a regular expression that defines a set of matching URLs.

    Request URL

    Depending on your selection in Type, enter either:

    • Simple String—The literal URL, such as /index.php, that the HTTP request must contain in order to match the input rule. The URL must begin with a backslash ( / ).

    • Regular Expression—A regular expression, such as ^/*.php, matching the URLs to which the rule should apply. The pattern does not require a slash ( / ), but it must match URLs that begin with a slash, such as /index.cfm.

    Do not include the domain name, such as www.example.com, which is configured separately in Host.

  7. Click OK.
  8. Reference the Exception in an HTTP Header Security Policy.