wiki : Technical documentation > Security headers

Security Headers

Introduction

HTTP headers are meta-information transmitted between the client and the server along with the data of a request or response. They are presented in the form of a name and a value separated by a colon. This value consists of one or more instructions called directives.

Security headers are a subset of HTTP headers added to responses and focused on security. They provide indications mainly intended for web browsers on how to behave regarding a page or document.

Thus, they offer an additional layer of security to applications and help protect against the most common attacks such as XSS or clickjacking attacks.

Some of them are not specifically identified as security headers but are also included in this group because they contribute to the security of an application (notably the Cache-Control header).

The OWASP Secure Headers Project

The OWASP (Open Worldwide Application Security Project) foundation, through the OWASP secure headers project, aims to promote security headers to increase the overall security level of applications on the Internet. The dedicated website can be found at this address : https://owasp.org/www-project-secure-headers/

On this site, OWASP has listed security headers classified by status. The possible statuses are :

• working draft
  
• active
  
• almost deprecated
  
• deprecated
  

From this list, OWASP has extracted a selection of headers to add to the responses generated by applications and offers recommended settings for each of them.

Security Headers in Lutèce

For Lutèce, the choice of security headers to add is based on this selection recommended by the OWASP secure headers project within the limits imposed by the application and its needs.

Only headers with the status "active" are retained. For obsolescence reasons, those with the status "almost deprecated" and "deprecated" are excluded. For the only header with the status "working draft," namely Permissions-Policy, OWASP advises not to implement it as long as it is in this state. It may be subject to change, and only browsers based on the Chromium engine support some of its features.

There are 2 types of headers in Lutèce : page-type headers and REST API-type headers.

Page-Type Headers

Page-type headers are added to pages sent by the server. They provide indications to the browser on how to behave regarding the returned page.

In Lutèce, there are currently 5 categories of pages to which security headers are added :

• Category "all pages"
  This category includes headers that are systematically added to every page of the application accessed by the user. Other more specific headers can also be added at the same time, such as those that follow.

• Category "FO pages with authentication"
  This category includes Front office pages that require user authentication. Note that some Front office pages, such as the login or logout page, are not part of it. The headers applied to this category of pages mainly aim to prevent confidential data from being stored in the cache.

• Category "BO pages with authentication"
  This category is the back office counterpart of the previous category.

• Category "FO logout page"
  This category corresponds to the Front office logout page. Currently, the headers added to the pages in this category aim to clear data that may have been stored on disk or in the cache, especially during navigation while the user was connected to the Front office.

• Category "BO logout page"
  This category is the back office counterpart of the previous category.

REST API-Type Headers

Although primarily intended for browsers, headers can also be useful in the case of REST API calls. In the configuration proposed by the OWASP secure headers project, it is indicated that it is proposed both in the context of a web application and an API. In Lutèce, REST API calls are made between services, and many of these headers are therefore not useful in this context.

As part of its cheat sheet series, OWASP offers a note on REST API security available at this address : https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html. In the Security Headers chapter, it indicates a configuration that is better suited to REST API calls. The configuration for Lutèce was defined following this note.

Configuration

A security headers management interface has been added to the System menu of the back office. It allows listing headers, creating, modifying, deleting, or enabling/disabling a header. Regarding the addition of headers to pages or REST API calls, the application uses the servlet filter mechanism to identify them and consults the configuration set up with the interface to determine which headers should be added to a response.

It is highly recommended to keep enabled the various headers enabled by default when initializing the Lutece site.

Detailed Presentation of Security Headers

Security headers list

Help with Configuring Security Headers

It is very likely that the default header configuration provided for Lutèce will need to be supplemented with the specifics of your application. Below are some guidelines to help you with this task.

General Recommendations

• It is advisable to gradually supplement the default configuration, validating your changes at each step to ultimately arrive at a configuration that includes both the initial setup for Lutèce and the specifics of your application. As a reminder, the browser console is very useful for achieving this result because the constraints that are not met are displayed, including the names of the directives in error. However, be careful as the displayed values sometimes do not fully reflect the set values, which can hinder problem resolution.
• It may also be useful to use different browsers to ensure that your changes work correctly, as the messages displayed can be more or less informative depending on the browser you choose.
• You can find recommendations on configuring security headers in this guide published by ANSSI (French National Cybersecurity Agency): https://cyber.gouv.fr/sites/default/files/2013/05/anssi-guide-recommandations_mise_en_oeuvre_site_web_maitriser_standards_securite_cote_navigateur-v2.0.pdf

Configuring *-src Directives in the Content-Security-Policy (CSP) Header

The CSP security header plays a crucial role in protecting your application. It will likely require configuration adjustments to work correctly with your site. The *-src directives in the CSP header all operate on the same principle, allowing you to restrict the resources that can be loaded or accessed from your site's pages. If multiple domains/URLs need to be allowed, you should add them to the directive's value list, separating them with a space as in the following example:

img-src 'self' https://mesimages.com https://img.com

For more information, you can consult the list of possible values for these directives at the following address in the Source List Reference section: https://content-security-policy.com/#source_list

Configuring Existing *-src Directives in the Lutèce Configuration

The directives present in the Lutèce CSP header configuration are as follows: img-src, script-src, style-src, connect-src, object-src and default-src.

External images loading : img-src directive

Used to define valid sources for images. If your site uses images from a different origin, you will need to add the domain where these images are hosted. For example, if you use the image https://owasp.org/assets/images/logo.png, you will need to adjust the default configuration as shown below:

img-src 'self' https://owasp.org data: blob:

External images scripts : script-src directive

Used to indicate valid script sources. The Lutèce configuration is 'self' 'unsafe-inline', meaning that only scripts with the same origin as your site can be loaded and executed. For example, if you use the Google Analytics platform by loading the external script https://www.google-analytics.com/analytics.js, the adaptation consists of adding the domain of this script to the Lutèce configuration:

script-src 'self' 'unsafe-inline' https://www.google-analytics.com

External CSS loading : style-src directive

Allows defining valid sources for stylesheets or CSS. Given that the Lutèce configuration is 'self' 'unsafe-inline', if you use stylesheets external to your site, the domain where they are hosted must be added to the list of valid sources authorized for styles. So, if you use CSS sheets from an external resource named https://css.sheets.org/exemple.css, for example, you will need to supplement the default configuration with the domain name of this resource as shown below:

style-src 'self' 'unsafe-inline' https://css.sheets.org

External calls (Ajax, websocket, ...) : connect-src directive

Used to control calls made to resources using the following interfaces: XMLHttpRequest (AJAX), WebSocket, fetch(), or EventSource. With the default configuration ('self' blob:), access to these resources will be denied if they are not hosted in Lutèce. In case of an error, you need to identify the domain names you are accessing and add them to the existing values for this directive. For example, suppose some of your pages make AJAX calls to an external API like Base adresse nationale with the URL https://api-adresse.data.gouv.fr, the content of the connect-src directive should be as follows:

connect-src 'self' https://api-adresse.data.gouv.fr blob:

Embedded objects (<embed>, <object> tags) : object-src directive

Indicates valid sources for and elements. This directive has a default value of 'none'. However, if your site requires the inclusion of embedded objects (which is not recommended), you will need to remove the 'none' value and replace it with the domain names you wish to authorize, as shown in the example below:

connect-src https://trusted-source.com

default-src directive

Allows setting a default value for all *-src type directives. In the Lutèce configuration, this directive is set to 'self', indicating that resources must have the same origin as the calling page. Therefore, all *-src type directives inherit this value unless they are redefined in the CSP header, such as script-src or style-src. Consequently, a directive like font-src, which does not appear in the Lutèce configuration, inherits the default value 'self'.
In principle, you do not need to change the value of this directive.

Configuring *-src Directives Not Present in the Lutèce Configuration

It is possible that errors may occur on *-src directives that are not part of the default Lutèce configuration. As previously mentioned, these directives inherit the value 'self' from the default-src directive configuration Taking the example of an application that accesses external audio or video files via the <audio> or <video>HTML tags, these resources will not be accessible. An error message will then be displayed in the browser console indicating that the security policy is not respected for the media-src directive in the CSP header. In this case, assuming the audio/video files are hosted on the site http://example.video-audio.com, you will need to add this directive to the other directives in the CSP header to redefine its value as shown below:

media-src 'self' http://example.video-audio.com