Websecurity Headers Basics

Released: Jan. 13, 2025 | Categories: Security Web
Author: samuelgiger

To enhance the security of websites, there are some simple headers that should be set on each site. These headers can help mitigate XSS or MITM attacks.

As more and more web applications are created, there is an incentive to enhance the security of web applications. Due to the nature of web applications, they need to be accessible worldwide. This exposes them to a wider attack vector. From Man-in-the-Middle (MITM) attacks and Cross-Site Scripting (XSS) to clickjacking attacks, cyberattacks have become more sophisticated than ever. Safeguarding your application requires a multifaceted approach. Many times, security headers are overlooked or forgotten. The OWASP (Open Web Application Security Project) provides valuable guidance on implementing security headers effectively.

In this blog post, we’ll explore what security headers are, their importance, and how they align with OWASP’s recommendations to create a robust security posture for your web applications.

What Are Security Headers?

Security headers enable the web server to instruct the browser on how to handle content transmitted via the HTTP protocol. These headers guide the browser on how to interact with the website's content, mitigate potential risks, and reduce the attack surface. The attack surface includes the following:
Preventing cross-site scripting (XSS) attacks.
Mitigating clickjacking attempts.
Controlling how resources are loaded and executed.
Enforcing secure connections.

Key Security Headers

Here are some of the most important security headers and their roles in protecting web applications. An enhanced description of these headers is available on the OWASP Secure Headers Project.

Content Security Policy (CSP)

The Content Security Policy header allows you to define where the browser is allowed to load resources from (e.g., scripts, styles, images, etc.). This helps mitigate XSS and other injection attacks.
Example:

Content-Security-Policy: default-src 'self'; style-src 'self' https://example.com/

The option `default-src` defines the fallback source for all unspecified directives. In this case, it is `'self'`, meaning all content must be loaded from the host itself. The `style-src` option specifies where stylesheets can be loaded. In addition to the host itself, the browser is also allowed to load stylesheets from `https://example.com/`. Additional sources can also be specified.
For more information about headers and their possible options, visit the OWASP Content Security Policy Cheat Sheet.
Implementation in NGINX
../sites-enabled/webpage

server {
    ...
    add_header Content-Security-Policy "default-src 'self'; style-src 'self' https://example.com/;" always;
    ...
}

Strict-Transport-Security (HSTS)

The HTTP Strict Transport Security (HSTS) header forces browsers to interact with the web application only over HTTPS, ensuring encrypted communication.
Example:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The `max-age` option sets the time in seconds for which the browser should remember to only access the site over HTTPS. The `includeSubDomains` option ensures that this setting also applies to subdomains. The `preload` directive instructs browsers to always access the site over HTTPS and registers the domain at https://hstspreload.org/, so it is consistently opened over HTTPS.
Implementation in NGINX
../sites-enabled/webpage

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

X-Frame-Options (XFO)

The X-Frame-Options response header protects against clickjacking attacks by preventing the site from being embedded in an iframe.
Example:

X-Frame-Options: DENY

NGINX sets this as a default value.

X-Content-Type-Options

This header prevents browsers from interpreting files as a different MIME type than specified, mitigating certain types of attacks.
Example:

X-Content-Type-Options: nosniff

NGINX sets this as a default value.

Referrer-Policy

This header controls how much referrer information is included when navigating away from your site, protecting user privacy.
Example:

Referrer-Policy: no-referrer

NGINX sets this as a default value.

Permissions-Policy

The Permissions-Policy header limits the use of certain browser features (e.g., geolocation, camera, microphone) by the application. This header defines which browser APIs can be used.
Example:

Permissions-Policy: camera=(self "https://example.com"), geolocation=()

There are multiple browser APIs available. For example, the `camera` API can be disabled with `camera=()`. If it should be allowed, you can specify values such as `camera=(self "https://example.com")`, allowing access from the site itself and delegating it to `https://example.com`.
For an overview of available browser APIs, visit the GitHub w3c/webappsec-permissions-policy Project. Implementation in NGINX
../sites-enabled/webpage

server {
    ...
    add_header Permissions-Policy "fullscreen=(), geolocation=(), microphone=(), camera=(), payment=(), accelerometer=(), autoplay=(), clipboard-read=(), clipboard-write=(), display-capture=(), usb=(), magnetometer=(), gyroscope=(), xr-spatial-tracking=()" always;
    ...
}

Conclusion

Security headers are a vital component of modern web applications. By implementing them according to OWASP’s guidance, you can significantly reduce your application’s vulnerability to common threats. While these measures don’t completely eliminate risks, they form a robust defense when combined with other security practices. Implementing security headers following OWASP-recommended best practices can improve the security of your web application.
To check if security headers are implemented, use a tool like Security Headers.

Sources:

https://owasp.org/ https://owasp.org/www-project-secure-headers/ https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html https://securityheaders.com/ https://hstspreload.org/ https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html