Strict CSP An advanced guide on Strict Content Security Policy Foreword This section is provided as a guide to help you understand the implications of a Strict CSP for your Nuxt application. Strict CSP is known to be hard to implement, especially for JS frameworks. You can read more about Strict CSP here. Our recommended values provide sensible defaults that will enable Strict CSP in your application with minimum effort. However you may encounter situations where you want to finetune your settings, which may imply some level of code refactoring. This guide walks you through the elements that you need to take into account. Useful links on CSP: W3C standards MDN documentation OWASP CSP cheatsheet Auth0 blog series on CSP , SPAs and finetuning Google's CSP Overview Google's CSP Evaluator The CSP challenges For modern Javascript frameworks such as Nuxt, a proprer implementation of CSP needs to solve three different challenges simultaneously: Resource Control The goal of CSP is to prevent your site from loading unauthorized scripts and stylesheets. In most cases, you don't have significant control over the resources that Nuxt is trying to load. Sometimes, you don't even know which resources are being loaded, and how they are being loaded (external or inlined), unless you start digging really deep to find out. The first step when designing your own CSP rules is therefore to identify which resources you want to authorize. Hydration Nuxt is designed as an isomorphic framework, which means that HTML is rendered first server-side , and then client-side via the hydration mechanism. While Nuxt Security can make a lot of the heavy-lifting to ensure everything is fine on the server-side, hydration is a mechanism by which the browser will sometimes inject scripts and styles in your application. Because CSP is designed to prevent scripts and styles injection, hydration requires carefully-crafted policies. The second step is to design rules that do not block hydration. Rendering Mode Nuxt is an SSR-first framework, but also provides support for SSG mode. In SSR mode, Nuxt is in charge serving your application (via the Nitro server), and therefore can control how the CSP policies are delivered. However in SSG mode, your files are delivered by your own static provider, so we cannot leverage Nitro to control CSP. This is why Nuxt Security uses different mechanisms for SSR (nonces) and SSG (hashes). The last step is to take into account the differences between SSR and SSG. Inline vs. External CSP treats inline elements and external resources differently. Inline elements Inline elements are elements which are directly inserted in your HTML. Examples include: < script >console. log ( 'Hello World' ) > < style > h1 { color : blue } External resources External resources are elements that are loaded from a server. Examples include: < img src = "https://example.com/my-image.png" > < script src = "/_nuxt/entry.065a09b.js" / > < link rel = "stylesheet" href = "https://cdn.jsdelivr.net/npm/bulma@0.9.4/css/bulma.min.css" /> Why they differ The difference between external and inlined elements is important in CSP terminology because of 2 reasons: 1. The danger is not the same. An external resource can be dangerous because it can load a malicious script (e.g. . For inline elements, CSP has no easy way to determine whether they are legit or not. Therefore CSP adopts a different (and quite brutal) first-line of defense against this issue: it forbids all inline elements by default. 2. The problem for Nuxt is not the same Nuxt applications typically insert lots of external and inline elements in a dynamic manner. While the insertion of external resources is not a huge problem (they can be whitelisted), the insertion of inline elements is a real issue with Nuxt because CSP then blocks the whole application. In summary, external elements are manageable via whitelisting, but inline elements are a true challenge for Nuxt. We need a mechanism to tell CSP which inline elements are legit and which are not. Allowing inline elements for Nuxt Fortunately, CSP provides several mechanisms to allow the dynamic insertion of legit inline elements. The available mechanisms depend on the CSP version that you are using. There are three versions available, the most recent being CSP Level 3. CSP Level 3 is supported by most modern browsers and should be the default approach. You can check adoption on caniuse Each level is backwards-compatible with the previous ones, meaning that If your browser supports Level 3, you can still write Level 1 policies If your browser only supports Level 2, it will ignore Level 3 syntax 'unsafe-inline' (CSP Level 1) In the oldest version (CSP Level 1), the only way to allow inline elements was to use the 'unsafe-inline' directive. This meant that all inline elements were allowed. This disabled the protection that CSP offered against inline injection, but it was the only way to make Nuxt work under CSP. In other words, CSP Level 1 has a binary approach to inline elements: either they are all denied, or they are all allowed. Obviously, allowing all unsafe inline scripts is not recommended: as it name implies, it is unsafe. But as a last resort and if everything else fails, you still have this option. Using 'unsafe-inline' is unsafe and therefore not recommended. However CSP Level 2 has safe alternatives. See below how you can indicate which inline elements should be allowed. Nonces and Hashes (CSP Level 2) CSP Level 2 introduced two mechanisms to determine which inline elements are allowed: nonces and hashes. Nonces A nonce is a unique random number which is generated by the server for each request. This nonce is added to each inline element and when the response arrives, the browser will see : < script nonce = "somerandomstring" >console. log ( 'Hello World' ) The server also sends the nonce in the HTTP headers: Content-Security-Policy: script-src 'nonce-somerandomstring' Now the browser can compare the two nonce values to determine that the inline element is valid. Hashes A hash is the SHA hash of the inline code. Hashes are not added to the inline elements, but the browser can hash the content of the inline script itself: < script >console. log ( 'Hello, World !!' ) The server sends the hashed value in the HTTP headers: Content-Security-Policy: script-src 'sha256-......' Now the browser can compare the hash received in the headers with the value it computed itself to determine that the inline element is valid. With CSP Level 2, we can now indicate which inline elements should be allowed and which ones should be rejected. Implications for Nuxt However, there are many important details that you should know: Hashes and Nonces cancel 'unsafe-inline' . In other words, all inline elements must have a nonce or hash. Therefore for Nuxt applications to work, it is critical that every single inline element is included. If one inline element is omitted, it will be blocked. Hashes and Nonces are primarily intended for inline elements . External resources are still supposed to be whitelisted the old way, i.e. by including the domain name or file name in the policy. However, CSP Level 2 added the option to also whitelist external resources by nonce, but not by hash . So: If you use nonce : Inline and external elements can be whitelisted by nonce. External elements can also be whitelisted by name. If you use hash : Inline elements can be whitelisted by hash. External elements still need to be whitelisted by name. Hashes and Nonces only work on scripts and styles . It is useless to use them on other tags ( , ,

Releases