Advanced CSP skills include: 1. Use 'strict-dynamic' to implement secure loading of dynamic scripts, and cooperate with random nonce to ensure the legitimacy of dynamically generated scripts; 2. Use connect-src and frame-src to control the network requests and iframe embedding sources of third-party SDKs; 3. Remove 'unsafe-eval' to disable the execution of eval-type functions; 4. Use report-to to report violations to debug and monitor CSP execution. These methods enhance security while ensuring the functionality of modern SPA applications.

If you are developing a modern JavaScript application, especially using SPAs (single-page applications) with frameworks like React, Vue, or Angular, you may find that the standard CSP (Content Security Policy) instructions are far from enough. To balance security and functionality, you need to control how scripts are loaded and executed in a more granular way.

The following are some advanced CSP instruction setting tips that can help you better protect your application while avoiding errors caused by too strict policies on the page.

strict-dynamic : Dynamic scripts can also be loaded safely

Many front-end frameworks will generate inline scripts at runtime or insert code through module loaders. At this time, the traditional whitelisting method (such as 'sha256-...' ) is not very suitable.

The solution is to use 'strict-dynamic' :

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

This setting means: as long as the script is loaded by a parent script with a legal nonce, it is considered a trusted source and no additional hash or domain name is required. This is great for scripts that are lazy to load modules or dynamically injected through packaging tools such as Webpack.

What should be noted is:

• It must be used with random nonce generated by the server.
• Do not hardcode the nonce value, new ones should be generated every time you request.
• Without 'strict-dynamic' , the dynamically loaded script will be intercepted because there is no hash or is not in the whitelist.

Control third-party script loading: connect-src and frame-src

If your application introduces third-party SDKs (such as burying points, payments, advertising, etc.), these services usually initiate network requests or embed iframes through scripts.

At this time, you can use the following instructions to limit their behavior:

• connect-src : Restrict which sources can be used for XMLHttpRequest, fetch requests.
• frame-src : Restrict which sources can be loaded as <iframe> content.

For example, suppose you use Google Analytics and Stripe payment components:

 Content-Security-Policy: connect-src 'self' https://analytics.google.com; frame-src 'self' https://checkout.stripe.com;

The benefits of doing this are:

• Prevent malicious scripts from secretly sending requests to other addresses.
• Even if a third-party service is attacked, the scope of impact will be limited.

But be aware that some SDKs may rely on multiple subdomains or CDN addresses, so be sure to test them in advance, otherwise it will easily lead to functional abnormalities.

Restrict execution of eval type: Disable dangerous functions

Some functions in JavaScript (such as eval() and new Function() ) execute code from strings, which is very dangerous for CSP.

By default, CSP allows these behaviors unless you explicitly prohibit:

 Content-Security-Policy: script-src 'self' 'unsafe-eval';

The above writing method actually allows the use of eval. For safer purposes, 'unsafe-eval' should be removed:

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

However, be aware that some libraries (such as earlier versions of Vue or Angular) may use new Function() internally, so it is best to do compatibility testing before upgrading.

Report violations: Record potential problems with report-to

Even if you have already set up your CSP, you may encounter some unexpected script loading failures. At this time, you can use report-to command to let the browser report the violation:

 Content-Security-Policy: default-src 'self'; report-to /csp-violation-report-endpoint;

Then you can record these reports on the backend to see if there are any errors or missed cases. This method is particularly suitable for early debugging on the Internet and can also be used as a long-term monitoring mechanism.

Report content usually includes:

• Intercepted resource URL
• Type of instruction that violates the rules
• Current page address

It is recommended to run in read-only mode for a period of time ( Content-Security-Policy-Report-Only ) first, and then enable forced interception after confirming that it will not affect the user's use.

Basically that's it. Setting up advanced CSP is not complicated, but it is easy to ignore details, such as third-party script path changes, framework dependence on eval, and how nonce is generated. Rational configuration can not only improve safety, but also help you discover potential safety hazards in a timely manner.

The above is the detailed content of Advanced CSP Directives for JavaScript Applications. For more information, please follow other related articles on the PHP Chinese website!