Learn more about headers that can keep your site safe and quickly look up the most important details. This article lists the most important security headers you can use to protect your website.
Tags: security
via Pocket https://ift.tt/3fr0ewT original site
May 24, 2021 at 08:42PM
Comments
from: github-actions[bot] on: 5/24/2021
Security headers quick reference
Learn more about headers that can keep your site safe and quickly look up the most important details.
This article lists the most important security headers you can use to protect your website. Use it to understand web-based security features, learn how to implement them on your website, and as a reference for when you need a reminder.
Security headers recommended for websites that handle sensitive user data:
Security headers recommended for all websites:
Cross-Origin Resource Policy (CORP)
Cross-Origin Opener Policy (COOP)
HTTP Strict Transport Security (HSTS)
Security headers for websites with advanced capabilities:
Cross-Origin Resource Sharing (CORS)
Cross-Origin Embedder Policy (COEP)
Before diving into security headers, learn about known threats on the web and why you’d want to use these security headers.
Before diving into security headers, learn about known threats on the web and why you’d want to use these security headers.
Protect your site from injection vulnerabilities #
Injection vulnerabilities arise when untrusted data processed by your application can affect its behavior and, commonly, lead to the execution of attacker-controlled scripts. The most common vulnerability caused by injection bugs is cross-site scripting (XSS) in its various forms, including reflected XSS, stored XSS, DOM-based XSS, and other variants.
An XSS vulnerability can typically give an attacker complete access to user data processed by the application and any other information hosted in the same web origin.
Traditional defenses against injections include consistent use of autoescaping HTML template systems, avoiding the use of dangerous JavaScript APIs, and properly processing user data by hosting file uploads in a separate domain and sanitizing user-controlled HTML.
- Use Content Security Policy (CSP) to control which scripts can be executed by your application to mitigate the risk of injections.
- Use Trusted Types to enforce sanitization of data passed into dangerous JavaScript APIs.
- Use X-Content-Type-Options to prevent the browser from misinterpreting the MIME types of your website’s resources, which can lead to script execution.
Isolate your site from other websites #
The openness of the web allows websites to interact with each other in ways that can violate an application’s security expectations. This includes unexpectedly making authenticated requests or embedding data from another application in the attacker’s document, allowing the attacker to modify or read application data.
Common vulnerabilities that undermine web isolation include clickjacking, cross-site request forgery (CSRF), cross-site script inclusion (XSSI), and various cross-site leaks.
Post-Spectre Web Development is a great read if you are interested in these headers.
Build a powerful website securely #
Spectre puts any data loaded into the same browsing context group potentially readable despite same-origin policy. Browsers restrict features that may possibly exploit the vulnerability behind a special environment called “cross-origin isolation“. With cross-origin isolation, you can use powerful features such as SharedArrayBuffer.
Encrypt traffic to your site #
Encryption issues appear when an application does not fully encrypt data in transit, allowing eavesdropping attackers to learn about the user’s interactions with the application.
Insufficient encryption can arise in the following cases: not using HTTPS, mixed content, setting cookies without the Secure attribute (or __Secure prefix), or lax CORS validation logic.
Content Security Policy (CSP) #
Cross-Site Scripting (XSS) is an attack where a vulnerability on a website allows a malicious script to be injected and executed.
Content-Security-Policy provides an added layer to mitigate XSS attacks by restricting which scripts can be executed by the page.
It’s recommended that you enable strict CSP using one of the following approaches:
- If you render your HTML pages on the server, use a nonce-based strict CSP.
- If your HTML has to be served statically or cached, for example if it’s a single-page application, use a hash-based strict CSP.
Example usage: A nonce-based CSP
Content-Security-Policy: script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline'; object-src 'none'; base-uri 'none';Recommended usages #
A CSP can be an extra protection against XSS attacks; you should still make sure to escape (and sanitize) user input.
1. Use a nonce-based strict CSP #
If you render your HTML pages on the server, use a nonce-based strict CSP.
Caution:
A nonce is a random number used only once. A nonce-based CSP is only secure if you can generate a different nonce for each response. If you can’t do this, use a hash-based CSP instead.
Generate a new script nonce value for every request on the server side and set the following header:
server configuration file
Content-Security-Policy: script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline'; object-src 'none'; base-uri 'none';In HTML, in order to load the scripts, set the nonce attribute of all