Dec 19, 2024 6:11:40 PM Jawad Lalouf
wiki : Technical documentation > Security headers > Security headers list
Security headers list
- List of Security Headers
- List of Page-Type Headers
- List of REST API-Type Headers
- Glossary
- Useful Information
List of Security Headers
The OWASP configuration is detailed in the following two chapters "List of page-type headers" and "List of REST API-type headers.". For each header, it is specified which configuration has been applied to Lutèce. If the OWASP recommendation has not been followed (header omitted or different values chosen), reasons are provided to explain why.
The following icons indicate the choice made for Lutèce regarding the addition of a header proposed by OWASP:
: The proposed header has been added, and the chosen values are those recommended
: The proposed header has been added, but the chosen values are different from those recommended
: The proposed header has not been added
List of Page-Type Headers
This list constitutes all the "active" headers that OWASP recommends adding to responses when the server returns a page.
Strict-Transport-Security
| Definition | Informs browsers that the site should only be accessible via HTTPS and that future access attempts via HTTP will be automatically switched to HTTPS. This helps prevent protocol downgrade attacks and cookie hijacking |
| Value recommended by OWASP | max-age=31536000; includeSubDomains |
| Value retained for Lutèce | max-age=31536000; includeSubDomains |
| Page category | all pages |
| Remarks | - The recommended values mean that this behavior will apply for 31536000 seconds (1 year) from the first response provided to the client by the server and that it also applies to subdomains (see the glossary at the bottom of the page for the definition of a subdomain) - This header only concerns sites that use the HTTPS protocol - It is ignored if client/server exchanges use the HTTP protocol |
| Compatibility with desktop browsers | Chrome 4+ Edge 12+ Firefox 4+ Opera 12+ Safari 7+ |
| Compatibility with mobile browsers | Chrome Android 18+ Firefox for Android 4+ Opera Android 12+ Safari on iOS 7+ Samsung Internet 1.0+ WebView Android 4.4+ |
X-Frame-Options
| Definition | Specifies whether the browser is allowed to display a page in a <frame>, <embed> or <object> element. It offers protection against clickjacking attacks |
| Value recommended by OWASP | deny |
| Value retained for Lutèce | no value as header not retained |
| Page category | no category as header not retained |
| Remarks | - The OWASP recommendation was not followed because this header has been made obsolete by the frame-ancestors directive present in the Content-Security-Policy header |
| Compatibility with desktop browsers | Chrome 4+ Edge 12+ Firefox 4+ Opera 10.5+ Safari 4+ |
| Compatibility with mobile browsers | Chrome Android 18+ Firefox for Android 4+ Opera Android 12+ Safari on iOS 7+ Samsung Internet 1.0+ WebView Android 4.4+ |
X-Content-Type-Options
| Definition | Indicates to the browser not to try to guess the MIME type of a resource and to rely on the content of the Content-Type header of the request |
| Value recommended by OWASP | nosniff |
| Value retained for Lutèce | nosniff |
| Page category | all pages |
| Remarks | - The only possible value for this header is nosniff |
| Compatibility with desktop browsers | Chrome 64+ Edge 12+ Firefox 50+ Opera 51+ Safari 11+ |
| Compatibility with mobile browsers | Chrome Android 64+ Firefox for Android 50+ Opera Android 47+ Safari on iOS 11+ Samsung Internet 9.0+ WebView Android 64+ |
Content-Security-Policy (CSP)
| Definition | Defines a security layer to detect or mitigate certain types of attacks, including XSS and data injection attacks |
| Value recommended by OWASP | default-src 'self'; form-action 'self'; object-src 'none'; frame-ancestors 'none'; upgrade-insecure-requests; block-all-mixed-content |
| Value retained for Lutèce | default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; connect-src 'self' blob:; object-src 'none'; frame-ancestors 'self'; upgrade-insecure-requests |
| Page category | all pages |
| Remarks | - The configuration chosen for Lutèce takes into account the constraints imposed by the existing code as well as by certain third-party libraries such as tinyMCE, for example. Its editor requires a specific configuration to be applied when a CSP header is defined to continue using this library (see https://www.tiny.cloud/docs/tinymce/latest/security/) - An incorrect configuration of this header can seriously compromise the functioning of an application - The configuration of this header is described in detail in the following table |
| Compatibility with desktop browsers | Chrome 25+ Edge 14+ Firefox 23+ Opera 15+ Safari 7+ |
| Compatibility with mobile browsers | Chrome Android 25+ Firefox for Android 23+ Opera Android 14+ Safari on iOS 7+ Samsung Internet 1.5+ WebView Android 4.4+ |
Detail of the Content-Security-Policy Header Configuration
The table below details each of the directives recommended by OWASP for the Content-Security-Policy header. A directive can be followed by 0, 1, or more values. The list of directives is available at the following address: https://content-security-policy.com/. The meaning of the icons is the same as for the headers but applied to the directives.
| Directive Name | Value recommended by OWASP | Value retained for Lutèce | Remarks | Compatibility with desktop browsers | Compatibility with mobile browsers |
|---|---|---|---|---|---|
| default-src | 'self' | 'self' | - Sets the defined value (default value) for all *-src directives such as script-src or img-src, for example - The value 'self' means that access to resources is only allowed if the caller has the same origin as the requested resource (see the glossary for the definition of origin) - If a -src directive is defined in CSP, its value replaces the default value - The value proposed by the tinyMCE library editor for this directive is 'none', which is too restrictive for Lutèce as some pages would no longer work. The proposal made by OWASP has therefore been retained | Chrome 25+ Edge 14+ Firefox 23+ Opera 15+ Safari 7+ | Chrome Android 25+ Firefox for Android 23+ Opera Android 14+ Safari on iOS 7+ Samsung Internet 1.5+ WebView Android 4.4+ |
| script-src | 'self' (value set by default-src) | 'self' 'unsafe-inline' | - Defines valid sources for loading and executing JavaScript scripts - It is not possible to apply the configuration proposed by OWASP because the value 'self' implies that inline JavaScript scripts, function calls via events (such as OnClick), and scripts called via an <a> tag would no longer work - The combination of values 'self' 'unsafe-inline' still enhances security (especially regarding attacks using jQuery) without changing the existing code | Chrome 25+ Edge 14+ Firefox 23+ Opera 15+ Safari 7+ | Chrome Android 25+ Firefox for Android 23+ Opera Android 14+ Safari on iOS 7+ Samsung Internet 1.5+ WebView Android 4.4+ |
| style-src | 'self' (value set by default-src) | 'self' 'unsafe-inline' | - Defines valid sources for loading and executing styles and CSS stylesheets - It is not possible to apply the configuration proposed by OWASP because there are inline style tags and div tags with a style attribute in the code. These would no longer work if the proposed configuration were applied - Just like the script-src sub-directive, the combination of 'self' and 'unsafe-inline' values still enhances security without touching the code | Chrome 25+ Edge 14+ Firefox 23+ Opera 15+ Safari 7+ | Chrome Android 25+ Firefox for Android 23+ Opera Android 14+ Safari on iOS 7+ Samsung Internet 1.5+ WebView Android 4.4+ |
| img-src | 'self' (value set by default-src) | 'self' data: blob: | - Defines valid sources for loading images - Adding the values data: and blob: to the 'self' value serves to allow data URLs (e.g., base64 images) and blob URLs as content sources for images. This addition is required by the tinyMCE library, which necessitates the addition of these two values in addition to the 'self' value | Chrome 25+ Edge 14+ Firefox 23+ Opera 15+ Safari 7+ | Chrome Android 25+ Firefox for Android 23+ Opera Android 14+ Safari on iOS 7+ Samsung Internet 1.5+ WebView Android 4.4+ |
| connect-src | 'self' (value set by default-src) | 'self' blob: | - Restricts the URLs that can be loaded using script interfaces. This includes XMLHttpRequest (XHR / AJAX), WebSocket, fetch(), <a ping>, EventSource, and Navigator.sendBeacon(). - Adding the value blob: to the 'self' value serves to allow blob URLs as content sources by script interfaces. This addition is required by the tinyMCE library, which necessitates the addition of this value in addition to the 'self' value | Chrome 25+ Edge 14+ Firefox 23+ Opera 15+ Safari 7+ | Chrome Android 25+ Firefox for Android 50+ Opera Android 14+ Safari on iOS 7+ Samsung Internet 1.5+ WebView Android 4.4+ |
| object-src | 'none' | 'none' | - Specifies valid sources for <object> and <embed> elements | Chrome 25+ Edge 14+ Firefox 23+ Opera 15+ Safari 7+ | Chrome Android 25+ Firefox for Android 23+ Opera Android 14+ Safari on iOS 7+ Samsung Internet 1.5+ WebView Android 4.4+ |
| frame-ancestors | 'none' | 'self' | - Specifies valid parents that a page can embed using <frame>, <iframe>, <object>, or <embed> tags - The configuration proposed by OWASP prohibits pages from being embedded in other pages regardless of origin. The value 'none' being too restrictive for Lutèce, the value 'self' was chosen as it limits the embedding of pages in other pages only if the parent pages have the same origin as the calling page | Chrome 40+ Edge 15+ Firefox 58+ Opera 26+ Safari 10+ | Chrome Android 40+ Firefox for Android 58+ Opera Android 27+ Safari on iOS 9.3+ Samsung Internet 4.0+ WebView Android 4.0+ |
| upgrade-insecure-requests | no value | no value | - Instructs browsers to treat all non-secure URLs (HTTP) as if they had been replaced by secure URLs (HTTPS) (see https://www.w3.org/TR/upgrade-insecure-requests/) - In other words, the HTTP URLs on the page will be rewritten by the browser to HTTPS before executing the request. Does not apply to external links (hyperlinks) on the page - Useful in the case of a site switching to HTTPS and whose URLs have not been or cannot be adapted to the HTTPS protocol - This directive has no value. It is sufficient for its name to be indicated for it to be operational | Chrome 43+ Edge 17+ Firefox 42+ Opera 30+ Safari 10.1+ | Chrome Android 43+ Firefox for Android 42+ Opera Android 30+ Safari on iOS 10.3+ Samsung Internet 4.0+ WebView Android 43+ |
| block-all-mixed-content | no value | directive not retained | - Prevents the loading of any resource via HTTP when the page uses HTTPS - This directive was not chosen for Lutèce for the following reasons: It is indicated as obsolete in the W3C specifications and may therefore cease to function at any time, MDN Web Docs recommends avoiding it, and it is incompatible with the upgrade-insecure-requests directive as the latter is evaluated before block-all-mixed-content, meaning the browser will ignore it (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/block-all-mixed-content#specifications) - This directive has no value. It is sufficient for its name to be indicated for it to be operational | Chrome compatible Edge 79+ Firefox 48+ Opera compatible Safari compatibility unknown | Chrome Android compatible Firefox for Android 48+ Opera Android compatible Safari on iOS compatibility unknown Samsung Internet compatible WebView Android compatible |
X-Permitted-Cross-Domain-Policies
| Definition | Used to limit the data that external resources, such as Adobe Flash (obsolete), PDF, Silverlight (obsolete), or Flex documents, among others, can access on the domain (see the glossary at the bottom of the page for the definition of a domain) |
| Value recommended by OWASP | none |
| Value retained for Lutèce | none |
| Page category | all pages |
| Remarks | - When this header has the value none, the browser must prevent other domains from embedding resources from the application in the content of documents generated by applications such as those listed in the header definition - Helps limit XSS attacks and cross-domain data leaks |
| Compatibility with desktop browsers | The only information found comes from the Adobe site and is as follows: Internet Explorer 5.5+ Firefox 2.0.0.4+ Safari 3.x+ |
| Compatibility with mobile browsers | No information found |
Referrer-Policy
| Definition | Used to indicate what information about the referrer can be sent in the Referer header of requests |
| Value recommended by OWASP | no-referrer |
| Value retained for Lutèce | no-referrer |
| Page category | all pages |
| Remarks | - The value no-referrer means that the Referer header will be completely absent from requests, and therefore no information about the referrer will be transmitted |
| Compatibility with desktop browsers | The information below concerns the support of the no-referrer value for this header: Chrome 56+ Edge 79+ Firefox 50+ Opera 43+ Safari 11.1+ |
| Compatibility with mobile browsers | The information below concerns the support of the no-referrer value for this header: Chrome Android 56+ Firefox for Android 50+ Opera Android 43+ Safari on iOS 12+ Samsung Internet 7.2+ WebView Android 56+ |
Clear-Site-Data
| Definition | Allows clearing browsing data related to the site. It is possible to precisely target the type of data to be cleared | |
| Value recommended by OWASP | "cache","cookies","storage" | |
| Value retained for Lutèce | "cache","cookies","storage" | |
| Page category | FO and BO logout pages | |
| Remarks | - The value "cache","cookies","storage" indicates that the server wants locally cached data, cookies (including HTTP authentication information), and DOM storage data related to the site to be cleared - Only works on https pages (or localhost) with certain browsers (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data) - The quotation marks surrounding each directive are important. Without them, the directive is considered invalid - Does not work with Safari at the moment | |
| Compatibility with desktop browsers | Chrome 61+ (61+ for cache, cookies, storage directives) Edge 79+ (79+ for cache, cookies, storage directives) Firefox 63+ (63+ for cache and storage directives, incompatible with the cookies directive since v94) Opera 48+ (48+ for cache, cookies, storage directives) Safari 17+ incompatible | |
| Compatibility with mobile browsers | Chrome Android 61+ (61+ for cache, cookies, storage directives) Firefox for Android 63+ (63+ for cache and storage directives, incompatible with the cookies directive since v94) Opera Android 45+ (45+ for cache, cookies, storage directives) Safari on iOS incompatible Samsung Internet 8.0+ (8.0+ for cache, cookies, storage directives) WebView Android 61+ (61+ for cache, cookies, storage directives) | |
Cross-Origin-Embedder-Policy
| Definition | Allows configuring the integration of cross-origin resources into the document |
| Value recommended by OWASP | require-corp |
| Value retained for Lutèce | require-corp |
| Page category | all pages |
| Remarks | - The value require-corp means that the document can access resources from the same origin as the caller or those specifically authorized by Cross-Origin-Resource-Sharing, either by the cross-origin attribute or by the value of the Cross-Origin-Resource-Policy header as recommended by OWASP |
| Compatibility with desktop browsers | Chrome 83+ Edge 83+ Firefox 79+ Opera 69+ Safari 15.2+ |
| Compatibility with mobile browsers | Chrome Android 83+ Firefox for Android 79+ Opera Android 59+ Safari on iOS 15.2+ Samsung Internet 13.0+ WebView Android 86+ |
Cross-Origin-Opener-Policy
| Definition | Ensures that a top-level document does not share a browsing context group with cross-origin documents |
| Value recommended by OWASP | same-origin |
| Value retained for Lutèce | same-origin |
| Page category | all pages |
| Remarks | - The value same-origin means that if a new window is opened from a page, the browsing context will only be shared if the opened window has the same origin as the page (see the glossary at the bottom of the page for the definition of the same-origin security policy) - Helps limit the risks of cross-origin attacks and session hijacking attacks |
| Compatibility with desktop browsers | Chrome 83+ Edge 83+ Firefox 79+ Opera incompatible Safari 15.2+ |
| Compatibility with mobile browsers | Chrome Android 83+ Firefox for Android 79+ Opera Android incompatible Safari on iOS 15.2+ Samsung Internet 13.0+ WebView Android incompatible |
Cross-Origin-Resource-Policy
| Definition | Allows controlling access to a site's resources based on the origin of the requests |
| Value recommended by OWASP | same-origin |
| Value retained for Lutèce | same-site |
| Page category | all pages |
| Remarks | - The value same-origin means that only requests from the same origin can access the page's resources. For example, an external site will not be able to directly point to resources of the site with this setting in its code - For Lutèce, the less restrictive value same-site was chosen to allow Lutèce sites sharing the same domain to access the resources |
| Compatibility with desktop browsers | Chrome 73+ Edge 79+ Firefox 74+ Opera 60+ Safari 12+ |
| Compatibility with mobile browsers | Chrome Android 73+ Firefox for Android 79+ Opera Android 52+ Safari on iOS 12+ Samsung Internet 11.0+ WebView Android 73+ |
Cache-Control
| Definition | Allows controlling the browser's caching behavior |
| Value recommended by OWASP | no-store, max-age=0 |
| Value retained for Lutèce | max-age=0, must-revalidate, no-cache, no-store, private |
| Page category | FO and BO pages with authentication |
| Remarks | - The value no-store indicates to clients (browsers and intermediaries like proxies or CDNs) not to store anything in permanent storage. It should be noted that some browsers will continue to use memory cache. As for the value max-age=0, it asks clients to cache the data for 0 seconds (no caching). Beyond this limit, the data is considered expired - In theory, the configuration recommended by OWASP should suffice to clear the cache, but in practice, some browsers may continue to use the cache or may not support the no-store directive. Therefore, to maximize the chances of clearing the cache, the directives must-revalidate, no-cache, and private were added to the configuration recommended for Lutèce (see https://grayduck.mn/2021/09/13/cache-control-recommendations/) - Cache deactivation is only performed on pages containing sensitive information as it can have a serious impact on performance. Additionally, some features require data to be cached |
| Compatibility with desktop browsers | Chrome compatible Edge 12 Firefox compatible Opera compatible Safari compatible |
| Compatibility with mobile browsers | Chrome Android compatible Firefox for Android compatible Opera Android compatible Safari on iOS compatible Samsung Internet compatible WebView Android compatible |
List of REST API-Type Headers
This list constitutes all the headers to be applied to REST API calls according to the previously mentioned cheat sheet series note on REST API security. Headers related to responses generated in HTML format have been ignored because in Lutèce, they are not generated in this format.
Cache-Control
| Definition | Allows controlling the browser's caching behavior |
| Value recommended by OWASP | no-store |
| Value retained for Lutèce | no value as header not retained |
| Remarks | - The recommended configuration was not retained primarily because some APIs need to store data locally. The no-store value is therefore not suitable for the Lutèce context |
Strict-Transport-Security
| Definition | Ensures that API calls are made via HTTPS and protects against forged certificates |
| Value recommended by OWASP | max-age=31536000; includeSubDomains |
| Value retained for Lutèce | max-age=31536000; includeSubDomains |
| Remarks | - The recommended values mean that this behavior will apply for 31536000 seconds (1 year) from the first response provided to the client by the server and that it also applies to subdomains (see the glossary for the definition of a subdomain) - This header concerns sites that use the HTTPS protocol - It is ignored if client/server exchanges use the HTTP protocol |
X-Frame-Options
| Definition | Specifies whether the response can be embedded in a <frame>, <iframe>, <embed> or <object> element. It offers protection against clickjacking attacks |
| Value recommended by OWASP | deny |
| Value retained for Lutèce | no value as header not retained |
| Remarks | - The OWASP recommendation was not followed because this header has been made obsolete by the frame-ancestors directive present in the Content-Security-Policy header |
X-Content-Type-Options
| Definition | Indicates to the browser not to try to guess the MIME type of a resource and to rely on the content of the Content-Type header of the request |
| Value recommended by OWASP | nosniff |
| Value retained for Lutèce | no value as header not retained |
| Remarks | - This header was not retained because it is not relevant in the context of Lutèce where REST API calls are used by services and responses are returned in JSON format (no HTML is generated) |
Content-Security-Policy (CSP)
| Definition | Defines a security layer to detect or mitigate certain types of attacks, including XSS and data injection attacks |
| Value recommended by OWASP | frame-ancestors 'none' |
| Value retained for Lutèce | frame-ancestors 'none' |
| Remarks | - Although a response to a REST API call is generally not intended to be embedded in a frame, if the case arises, the value frame-ancestors 'none' prevents any domain from adding the response returned by the REST API in a frame to prevent a clickjacking attack |
Content-Type
| Definition | Specifies the content type of a response |
| Value recommended by OWASP | response content type |
| Value retained for Lutèce | response content type but must be added by the APIs |
| Remarks | - The generation of the Content-Type header in responses is the responsibility of the API itself because it holds the information about the response content type. It is not up to the filter responsible for adding headers to REST API calls to handle this header |
Glossary
Domain
The domain (or domain name) corresponds to a physical IP address on the internet. In the address http://lutece.paris.fr, paris.fr is the domain.
Origin
The origin is defined by the protocol/host/port triplet. If the port number is not specified, it is equal to 80 if the connection is made in HTTP and 443 if the connection is made in HTTPS. Thus, two URLs have the same origin if they have exactly the same protocol, the same host name, and the same port number, like the two following URLs: https://lutece.paris.fr/support/wiki/architecture-overview.html and https://lutece.paris.fr/support/wiki/plugin-wizard.html
Same-origin policy
The same-origin security policy is implemented in browsers and only concerns scripts. It does not apply to images, CSS, and dynamically loaded scripts. On a given page, it prohibits the execution of scripts that do not have the same origin as that of the page. This policy can be relaxed by various mechanisms, including Cross-Origin Resource Sharing (CORS).
Site
A site is a set of web pages from the same domain maintained by the same organization. Unlike the origin, the protocol and port number do not come into play to identify a site. The following two URLs have the same domain, the domain here being paris.fr: https://www.paris.fr/, https://lutece.paris.fr/fr/.
Subdomain
A subdomain is a domain that is part of another domain. For example, in the addresses http://lutece.paris.fr and http://www.paris.fr, the subdomains are respectively lutece and www.
Useful Information
- With the browser console, it is possible to check on each page whether the conditions defined for a security header are met or not. In case of non-compliance, an explicit message is displayed in the console as shown below with Firefox:
- With the network tools of browsers (Menu "Network" > Submenu "Headers" > section "Response Headers" in Firefox, for example), it is possible to display the security headers that are returned with a response by clicking on the line corresponding to the generated page as shown below:
- To help modify the Content-Security-Policy header configuration, there is another header named Content-Security-Policy-Report-Only which is identical to Content-Security-Policy but instead of applying the defined restrictions, it only displays the constraints that were not met in the browser console. It is also capable of sending a report to an endpoint of your choice. It can be used in conjunction with the Content-Security-Policy header to gradually validate a given configuration