Use HSTS and CSP. Just. Do. It.

September 2nd, 2022

First things first.
HSTS = HTTP Strict Transport Security
CSP = Content Security Policy

HSTS will protect you against man-in-the-middle (MITM) attacks AND cookie hijacking.
CSP will protect you against Cross-Site Scripting (XSS) and data injection attacks.

That's not so bad for a 10 min configuration.

HSTS configuration on nginx

Log on your webserver.
Go to your nginx directory.
Find your nginx website configuration. Usually:

					
$ cd /etc/nginx/sites-enabled
$ ls
example.com
					

Open your example.com configuration file.
Add the following line:

					
server {
...
	add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";
...
}

					

Save your change.

Verify your new configuration using:

					
$ nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

					

Restart your nginx service with:

					
$ sudo systemctl restart nginx

					

OK so, what have we just done here?
We just configured our webserver to define that:

• max-age=31536000: Everyone that have already visited your website for the next 1 year will immediately go for the HTTPS page and no longer the HTTP first, then being redirected.
• includeSubdomains: All you sub-domains are also affected.
• preload: Even the first time a user will connect to your website, he will go to the HTTPS page instead of the HTTP. For this to work, you *MUST* register your website here: https://hstspreload.org/

CSP configuration on nginx

You go to the exact same file as for HSTS configuration.

					
...
add_header Content-Security-Policy "default-src 'self'; script-src 'none'; connect-src 'self'; 
				    img-src 'self'; style-src 'self'; font-src 'self';>
...

					

Let's go through the possible parameters:

• default-src : Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback)
• script-src : Define which scripts the protected resource can execute
• object-src : Define from where the protected resource can load plugins
• style-src : Define which styles (CSS) the user applies to the protected resource
• img-src : Define from where the protected resource can load images
• media-src : Define from where the protected resource can load video and audio
• frame-src : Define from where the protected resource can embed frames
• font-src : Define from where the protected resource can load fonts
• connect-src : Define which URIs the protected resource can load using script interfaces
• form-action : Define which URIs can be used as the action of HTML form elements
• sandbox : Specifies an HTML sandbox policy that the user agent applies to the protected resource
• script-nonce : Define script execution by requiring the presence of the specified nonce on script elements
• plugin-types : Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded
• report-uri : Specifies a URI to which the user agent sends reports about policy violation

Each parameter can have one of the following values:

• 'self': Refers to the origin from which the protected document is being served, including the same URL scheme and port number. You must include the single quotes. Some browsers specifically exclude blob and filesystem from source directives. Sites needing to allow these content types can specify them using the Data attribute.
• 'unsafe-eval' : Allows the use of eval() and other unsafe methods for creating code from strings. You must include the single quotes.
• 'wasm-unsafe-eval' : Allows the loading and execution of WebAssembly modules without the need to also allow unsafe JavaScript execution via 'unsafe-eval'. The single quotes are required.
• 'unsafe-hashes' : Allows enabling specific inline event handlers. If you only need to allow inline event handlers and not inline <script> elements or javascript: URLs, this is a safer method than using the unsafe-inline expression.
• 'unsafe-inline' : Allows the use of inline resources, such as inline <script> elements, javascript: URLs, inline event handlers, and inline <style> elements. The single quotes are required.
• 'none' : Refers to the empty set; that is, no URLs match. The single quotes are required.
• 'nonce-<base64-value>' : An allow-list for specific inline scripts using a cryptographic nonce (number used once). The server must generate a unique nonce value each time it transmits a policy. It is critical to provide an unguessable nonce, as bypassing a resource's policy is otherwise trivial. Specifying nonce makes a modern browser ignore 'unsafe-inline' which could still be set for older browsers without nonce support.
• '<hash-algorithm>-<base64-value>' : A sha256, sha384 or sha512 hash of scripts or styles. This value consists of the algorithm used to create the hash followed by a hyphen and the base64-encoded hash of the script or style. When generating the hash, exclude <script> or <style> tags and note that capitalization and whitespace matter, including leading or trailing whitespace.
• 'strict-dynamic' : The strict-dynamic source expression specifies that the trust explicitly given to a script present in the markup, by accompanying it with a nonce or a hash, shall be propagated to all the scripts loaded by that root script. At the same time, any allow-list or source expressions such as 'self' or 'unsafe-inline' are ignored.
• 'report-sample' : Requires a sample of the violating code to be included in the violation report.

The above parameters and values explanation are a copy & paste of the following documentation available online: Mozilla documentation and OWASP documentation.

Now with this information, you do your own mixture, you modify the nginx configuration file, you test, you reload and you are happy because you have implemented web standard from 2013!

Do not forget to test and verify that your mixture is correct and you haven't forgotten anything using the following: Security Headers

Let's make the web a safer place all together!