CSP (Content-Security-Policy) is a front-end security mechanism that prevents malicious code injection such as XSS. 1. It declares which resources can be loaded and executed through the HTTP response header. The core idea is the "whitelist" policy; 2. The setting method is to add Content-Security-Policy fields to the server response header, such as default-src, script-src and other instructions to control different resource types; 3. Inline scripts and eval are blocked by default, and can be temporarily allowed through nonce or hash, but external script files are recommended; 4. Content-Security-Policy-Report-Only can be used for testing and collecting violation reports during the development stage. After it is launched, strict policies are enabled to ensure normal security and functions.

CSP (Content Security Policy) is an important mechanism for front-end security, which can effectively prevent malicious code injection behaviors such as XSS (cross-site scripting attacks). Properly configuring CSP in JavaScript projects can not only enhance the security of the website, but also avoid some unnecessary resource loading problems.

What is CSP?

Simply put, CSP is a declarative security mechanism that uses the HTTP response header Content-Security-Policy to tell the browser which resources can be loaded, executed and which cannot be. For example, you can restrict the page from loading scripts of the same origin, prohibit the execution of inline scripts, and do not allow the loading of pictures of unknown origin, etc.

The core idea of CSP is "whitelist", which means that only content you trust is allowed to run, and all other things will be intercepted. This is especially important for modern web applications, especially sites that use a large number of third-party scripts or user-generated content.

How to set up a CSP?

The most common way to enable CSP is to add Content-Security-Policy field in the server response header. For example:

 Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com

The above line indicates that by default all resources can only be loaded from the current domain name, and the script can also be loaded from https://trusted-cdn.com .

Common instructions include:

• default-src : Default policy, applicable to resource types that are not specified separately.
• script-src : Controls where JS can be loaded.
• style-src : controls CSS loading.
• img-src : controls the source of the image.
• connect-src : Controls the destination address of AJAX request.
• object-src : Controls the loading of plug-ins such as Flash (it's basically not used now).
• font-src : font file source.
• frame-src or child-src : the source of nested content such as iframe.

You can combine these instructions according to actual needs and gradually tighten the strategy.

Issues with inline scripts and eval

For convenience, many websites will write <script>...</script> directly or use eval() to execute string code. But CSP blocks this type of behavior by default because they are a common entry point for XSS attacks.

If you have to use inline scripts, there are several ways to bypass the limitations:

• Use nonce : Add a one-time key to a specific <script> tag, and the server declares that nonce is allowed in the CSP.

  Example:

   Content-Security-Policy: script-src 'nonce-abc123';

  HTML:

   <script nonce="abc123">alert(&#39;allowed&#39;);</script>

• Use hash : hash the content of the inline script and allows the hash in the policy.

  Example:

   Content-Security-Policy: script-src 'sha256-abc...';

However, neither method is recommended to use frequently because it is troublesome to maintain and is prone to errors. A more recommended approach is to move the script to an external file, which makes it easier to manage and review.

As for methods that dynamically execute code such as eval() and new Function() , by default, it is controlled by 'unsafe-eval' . It is recommended to avoid using it as much as possible or explicitly prohibit it.

Strategic differences between development and online stages

In development environments, we usually want to debug easily, so CSP can be a little looser, such as allowing scripts from any source to load, or even allowing inline scripts. However, when it comes to the production environment, strict restrictions should be strictly allowed to load only necessary resources.

It can be achieved through two different policy headers:

• Content-Security-Policy for online environments
• Use Content-Security-Policy-Report-Only in the development environment. This header will not really prevent resource loading, it will only report violations, which is suitable for testing.

For example:

 Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-violation-report-endpoint/

In this way, you can observe whether the current page violates CSP without interrupting the function, and then gradually adjust the strategy.

In addition, it is recommended to do a complete CSP check before deployment to ensure that there are no missing key resources, otherwise the page function may be abnormal.

Basically that's it. CSP is not complicated but it is easy to ignore details. Especially in large-scale projects, it is very important to plan a good strategic structure in the early stage.

The above is the detailed content of Deep Dive into JavaScript Content Security Policy (CSP). For more information, please follow other related articles on the PHP Chinese website!