• Ashan Fernando
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: zenblo
  • Proofreader: HurryOwen

Content security policies improve JavaScript security

How confident are you that your JavaScript code is safe from attacks? And why worry about it? When we look at modern Web applications, one of the things they have in common is that they all use JavaScript. In some applications, JavaScript plays to its strengths and contributes most of the code. One of the important properties of JavaScript is that the code we write executes in the user’s browser, where we have limited access.

Although we have very little control over the execution environment, it is critical to ensure that JavaScript is secure and that we have control over what we do.

Can you ensure that operating the browser follows a set of guidelines and executes JavaScript code? After reading this article, you will learn about common attributes of content security policies and how to use them to protect JavaScript code at run time.

Content security Policy

Content Security Policies (CSP) are an additional layer of security that helps detect and mitigate certain types of attacks, including cross-site scripting (XSS) and data injection attacks. These attacks can be used for everything from stealing data and damaging sites to distributing malware.

As the name suggests, a CSP is a set of instructions that can be sent to the browser with JavaScript code to control its execution. For example, you can set the CSP to restrict JavaScript execution to a set of whitelisted fields, while ignoring any inline scripts and event handlers to protect against XSS attacks. In addition, you can specify that all scripts should be loaded over HTTPS to reduce the risk of packet sniffing attacks.

So how do I configure a CSP for a Web application?

There are two ways to configure a CSP: either by returning an HTTP header containing a specific content security policy, or by specifying a
element in an HTML page.

Let’s look at an example of a CSP

Suppose you have set the following content security policies for your Web application:

Content security policy: default-src'self'; script-src'self'https ://example.com;Copy the code

This will then allow JavaScript to be loaded, for example from https://example.com/js/*, but blocked someotherexample.com/js/* by the browser specified in the CSP. Also, by default, all inline scripts are blocked unless you allow them to be executed using hash or random numbers.

If you haven’t heard of hashing or random numbers, I strongly encourage you to look at this example to see its true potential.

In short, with the hash operation, you can specify the hash of a JavaScript file as an attribute of aScript block in which the browser will first validate the hash before performing it.

The same is true for random numbers. We can generate a random number and specify it in the CSP header, while referencing the same random number in the Script block.

How do you determine if there is any violation of the CSP?

The advantage of the CSP is that it covers reporting violations to you. As part of the CSP, you can define a URL from which the user browser will automatically send a violation report to your server for further analysis.

To do this, you need to set up an endpoint to handle the POST load sent by the browser as a CSP violation report. The following shows an example of specifying the path /csp-incident-reports receives the violation report payload.

Content security policy: default-src'self'; report-uri / csp-incident-reportsCopy the code

If we include JavaScript or styles outside of the site’s own source (e.g. Otherdomain.com), then when we visit the site URL (e.g. Example.com), The above policy will refuse to load it into the browser and submit the following violation report as HTTP POST load.

{@@-67,23 +67,23 @@if we include a JavaScript or Style outside the sites own origin (LLDB; otherdoma }Copy the code

Supported browsers and tools

As you can see, all major browsers support CSP functionality. This is good news because our investment in creating CSPS can cater to a much larger user base.

In addition, browsers like Chrome go further by providing tools to validate CSP properties. For example, if you define a JavaScript hash, the Chrome developer console will promote the correct hash for the developer to correct all errors.

Also, if you bundle JavaScript with Webpack, you can find a plug-in called the CSP HTML Webpack Plugin that appends hash values at build time to automate the process.

conclusion

After observing multiple projects, you often forget to set up content security policies due to a gap in awareness. I hope this article has convinced you how to set up a CSP in an ongoing project.

However, before creating a CSP, it is also important to do a proper analysis of all the resources used in your application. This way, you can create a more restrictive CSP by whitelisting all known resources and blocking others by default.

I hope you feel free to ask any questions or make any suggestions. You can mention them in the comment box below.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.