HTTP Response Headers
Summarize
Summary of HTTP Response Headers
HTTP response headers are name-value pairs in an HTTP response that provide additional information about page content and guide how clients, typically browsers, should process it. ServiceNow allows for configuration of these headers for all or specific types of pages, enabling special handling of content.
Show less
Key Features
- Configuration Options: Headers can be configured for Service Portal, UI Page, or UX applications.
- Security Considerations: Be cautious when using custom name-value pairs in URLs due to potential security risks. You can disable HTTP response header configurations by setting the glide.http.headersconfig.enabled property to false.
- Content-Security-Policy Handling: The X-Frame-Options: SAMEORIGIN header is automatically included unless the Content-Security-Policy: frame-ancestors 'self' directive is used.
- Internet Explorer Compatibility: For Internet Explorer, the platform will utilize X-Frame-Options: ALLOW-FROM URL if the Content-Security-Policy is configured for multiple URLs.
Key Outcomes
By effectively configuring HTTP response headers, ServiceNow customers can enhance content security and control how their pages are displayed in browsers, ensuring better compliance with security policies. Understanding the nuances between different headers allows for optimized web application performance and security, especially when dealing with multiple browser environments.
A response header is a simple name-value pair used in an HTTP response to provide additional information about page content or how the client should process it.
You can configure HTTP response headers for all, or specific types of pages, which include Service Portal, UI Page, or UX applications. The ability to configure and pass response headers enables special handling of the page content by a client, most typically a browser.
To learn more about what an HTTP header is, and about configuring the name-value pair for specific HTTP response headers, see:https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
- For example, you configure an HTTP header for a specific page or all the pages with a Content-Security-Policy: frame-ancestors 'self' https://www.servicenow.com.
- When you invoke the page in a browser such as Chrome, you can review it in the Response
Headers section of Chrome Developer Tools.
To learn more about how browsers handle a page with frame-ancestors, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors.
- If you want to entirely disable HTTP response header configuration functions, set the glide.http.headers_config.enabled property to false.
- Once you set it to false, ServiceNow AI Platform does not use any of the header configurations you defined in the sys_response_header table.
Special handling of the Content-Security-Policy: frame-ancestor header
- It supports use of this header in all types of browsers, based on the setting of the glide.set_x_frame_options global property, which is enabled by default.
- When you configure a page with a Content-Security-Policy: frame-ancestor 'self' URL1 URL2 header, the ServiceNow AI Platform does not automatically include the X-Frame-Options: SAMEORIGIN header. Excluding it prevents the browser from being confused, because Content-Security-Policy: frame-ancestor 'self' already has a similar effect.
Special handling of Content-Security-Policy: frame-ancestor header for Internet Explorer
- Instead, the Internet Explorer only supports the X-Frame-Options: ALLOW-FROM URL (ALLOW-FROM) directive in this header, although the restriction is for a single host URL.
- If you configure the frame-ancestor 'self' URL1 URL2 header, and Internet Explorer is in use, the ServiceNow AI Platform automatically uses the X-Frame-Options: ALLOW-FROM URL (ALLOW-FROM) header instead.
- It attempts to match it with the host URLs (full or wildcard http://*.example.com type URL format only) configured in the Content-Security-Policy: frame-ancestor 'self' URL1 URL2 header.
- If there is a match, include the matched URL as X-Frame-Options: ALLOW-FROM URL1.
- If there is no referrer header, it uses the first non-wildcard based host URLs configured in the Content-Security-Policy: frame-ancestor 'self' URL1 URL2 header.
- This example of an incorrect configuration that may not work properly with this
special handling:
- Name: Content-Security-Policy
- Value: frame-ancestors 'self' https://microsoft.com/
- Use this correct syntax instead:
- Name: Content-Security-Policy
- Value: frame-ancestors 'self' https://microsoft.com