Content Security Policy (CSP) prevents attacks such as XSS by limiting the loading source of web page resources. Its core mechanism is to set a whitelist to prevent unauthorized scripts from being executed. The steps to enable include: 1. Define the policy and clarify the allowed resource sources; 2. Add Content-Security-Policy HTTP header to the server; 3. Test and debug in the early stage using Report-Only mode; 4. Continuous monitoring and optimization strategies to ensure that they do not affect normal functions. Notes include handling inline scripts, careful use of third-party resources, compatibility support, and other irreplaceable security measures.

Content Security Policy (CSP) is a security mechanism that helps websites prevent and reduce malicious script attacks. Simply put, it prevents security vulnerabilities like XSS (cross-site scripting attacks) from being exploited by telling the browser which resources can be loaded and which cannot be.

Its core idea is: not all resources should be loaded, only the sources of your trust should be allowed to be executed.

Why do you need a CSP?

Without CSP, the web page will load any embedded scripts, styles or even images by default, which gives attackers an opportunity to take advantage of. For example, a malicious user submits a piece of JavaScript code. If the page does not filter enough, the code will be executed, which may steal the user's cookies and initiate a forgery request.

The function of CSP is to restrict the page from loading content from the specified source . Even if someone inserts malicious code, the browser will not execute it as long as it does not come from the resource on the whitelist.

For example:

• When there is no CSP, the attacker injects <script src="https://malicious.com/evil.js"></script> and the browser loads as usual.
• With CSP and setting only allows loading JS from your own server, this external script will be intercepted.

How does CSP work?

CSP passes policy rules through HTTP response header Content-Security-Policy . After the browser receives this header, it will judge whether a resource is allowed to be loaded according to the rules.

Common CSP instructions include:

• default-src : Default policy for other resource types that are not specified separately
• script-src : Control where JavaScript can be loaded
• style-src : Controls the loading source of CSS stylesheets
• img-src : control image source
• connect-src : Control the target of network requests such as XMLHttpRequest, fetch, etc.

Let's give a simple strategy example:

 Content-Security-Policy: script-src 'self'; object-src 'none';

The meaning of this strategy is: JavaScript can only be loaded from the current domain name and does not allow any Flash or other plug-in objects to be loaded.

How to get started with CSP?

To enable CSP, the main steps are as follows:

1. Define the policy content

   • Determine which resources can be loaded from which sources according to your website structure
   • You can relax first and then gradually tighten

2. Add HTTP header

   • Add Content-Security-Policy header in server configuration
   • For example, in Nginx, you can add this:

      add_header Content-Security-Policy "script-src 'self'; style-src 'self' https://cdn.example.com;";

   • Testing and debugging

     • In the early stage, it is recommended to use Content-Security-Policy-Report-Only mode to allow the browser to report violations but not really block them.
     • You can send logs to the specified address for analysis in combination with report-uri or report-to

   • Monitoring and Optimization

     • See which resources are intercepted and adjust the policy until it does not affect normal function

   ---

   Frequently Asked Questions and Notes

   • Inline scripts will be blocked

     • If you use <script>console.log(&#39;hello&#39;)</script> writing method, it will be blocked by CSP by default
     • Solution: Use external link JS file instead, or add a nonce signature

   • Be careful with third-party resources

     • When using CDNs or statistics codes, remember to whitelist them
     • Otherwise, it may cause styling disorders and function failure.

   • Compatibility is generally good

     • Mainstream modern browsers support CSP
     • But old versions of IE may not be recognized

   • Don't rely too much on CSP

     • It is an "additional layer" and cannot replace basic security measures such as input filtering, output escape, etc.

   ---

   In general, CSP is a tool that effectively improves front-end security. Although configuration is a bit troublesome at the beginning, once set up, it can significantly reduce the risk of attacks such as XSS. Basically that's all. If your website is already online, you might as well try it in the report-only mode.

   The above is the detailed content of What is content security policy CSP. For more information, please follow other related articles on the PHP Chinese website!