Use Content Security Policy (CSP) headers to prevent loading of untrusted resources and mitigate cross-site scripting (XSS) attacks

Did you know that your website might be at risk of loading untrusted external scripts? If your website doesn't explicitly trust the sources for all of its JavaScript, CSS, images etc., an attacker might be able to exploit this vulnerability by injecting a malicious script and possibly extract sensitive information from your website and your users.

CSP is a built-in browser security feature that is designed to prevent this "attack-vector" and is luckily one of the low-hanging fruits you can apply to secure your site.

Definitions

Before moving ahead let's define a few key concepts in this article.

Attack-vector

An attacker exploits a vulnerability by using a technical approach or method to access/inject/scan assets. This approach is often referred to as a vector. There might be one or more vectors for any given vulnerability, varying in difficulty to execute.

Source-origins

If your website's webserver hosts your JavaScript, CSS, images etc. then those are "own origin" or "self origin".

If your website uses third-party resources then those have "external origins".

CSP's directives supports self for own origins and URLs for external origins.

Get started

Your server should return the HTTP response header:

The header is made up of one or more directives (Directive Reference) for trusting source origins for JavaScript (script-src), CSS (style-src), fonts (font-src), frames (frame-src) and more.

Server-side configuration will vary depending on your server. Helmet for Express.js is a great option for those running a JavaScript/Node stack.

If you want to start with just trusting your own resources, use:

This tells your browser "hey, just load resources from my own domain/origin.". This mitigates Cross-Site Scripting (XSS) attacks where an attacker is trying to exploit a vulnerability on your website by injecting a script into your website from e.g. http://www.evil.com/evil.js.

Go to Content-Security-Policy.com or MDN to learn more about other types of directives and their use.

Advanced techniques

Report CSP-violations

When a browser attempts to load a resource but is blocked by the CSP-rules, it can report the CSP-violation by posting to a URL using the report-uri directive:

This lets you identify if someone's attempting something malicious or if you just forgot to whitelist one of your resources. Either way it's a useful tool to monitor your CSP-rules in production.

You need to implement a back-end to consume the report or use an external service, e.g. report-uri as a service.

Nonces

A cryptographic nonce (number used once) can be used to make exemptions to your CSP-rules. By generating a unique one-time use value on the server-side and providing it to the front-end, you can trust that the content you are allowing to pass-through your CSP-rules is yours and trusted.

Using just unsafe-inline as a broad catch-all method of allowing all inline JavaScript (or CSS for that matter) is not advisable:

A better way of making exemptions is to provide a value to the nonce attribute on the <script> blocks that are the inline JavaScript you need to whitelist:

Generate the random one-time use nonce value server-side

Provide the value in your Document Object Model (DOM) <script> block as the nonce attribute value:

Add it to your CSP-rule:

As long as the two nonce values match it will not be possible to inject JavaScript that doesn't have 2726c7f26c as nonce value.

Remember to re-generate the value per page-load and keep the nonce value random.

Another nonce technique is to use SHA256 to hash the inline JavaScript (Hashes).

Content Security Policy

You've probably seen someone on the internet write funny-looking but runnable JavaScript code using only six different characters. But how does that actually work?

You can write basically any JavaScript program on the planet without using any more than these characters:

You've probably seen or heard about this already (it's been quite Twitter-friendly).

In today's JavaScript article, we're gonna look at how this works under the hood. Let's task ourselves with creating a string using only our funny little subset of characters.

Our target string will be "self".

(Because the language Self was one of the inspirations Brendan Eich had in mind when he created JavaScript).

Let's go!

What allows us to make all other characters superfluous is the fact that we can abuse JavaScript's weak type system and bizarre type conversion mechanisms.

We'll be using our six superhero characters this way: with [] we can create arrays, with the negation and addition operators ! and + we can do operations on them and finally use () to group operations.

Let's start off with a simple array:

Negating an array with ! will coerce the array into a boolean. Arrays are considered to be truthy, so negating it produces false:

When adding values of different types together, JavaScript follows a pre-defined set of rules for what the values should be converted to, in order to actually add them together.

In the expression 2 + true, JavaScript will convert true to a number, resulting in the expression 2 + 1.

In the expression 2 + "2", JavaScript will convert the number of a string, resulting in 2 + "2" === "22".

These conversion rules aren't that bad, but it gets quite interesting quite quickly with other types.

Fun with arrays

Adding arrays together will convert them both to strings and concatenate them.

The same will happen when adding an array with something else, lets say, a boolean.

Aha! Now we're conjured a string containing the characters we need to produce our end goal, the string "self".

If we only had a number or four, we could extract the characters we need in the right sequence..

Let's go looking for numbers!

Fun with arrays part II

In the previous section, we coerced an array to a boolean. What happens if we coerce it to a number using +?

JavaScript will attempt to call valueOf on the array, which will fail and fall back to a simple toString();

Coercing a string to a number will produce the following results:

Thus:

Aha! Now we have a number, albeit not a very useful one. However, we can keep playing the coercion game:

Negating zero will make the falsy value of zero into a truthy boolean. A truthy boolean as a number becomes... one!

Hooray! One one can become two ones... which is two. You get the point.

Using the substitutions we've learned to create numbers:

Putting it all together

Let's put together all the things we've learned.

Our final expression thus becomes:

Adapting our expression to this specific JavaScript dialect, where newlines and whitespaces are, of course, banned:

Easy as pie!

Thank you, Brendan Eich ❤️

Writing JavaScript With Only Six Characters

Let's deal with those pesky errors once and for all

Don't you just hate errors? They are the worst. They come in when you least expect it, and ruin a perfectly good user experience. They might put your app in a half-broken state, and there aren't any great ways to report errors in a consistent way.

Let's fix that.

Let me introduce error boundaries

With React 16, we got a new feature called "error boundaries". They are special components that implement a few special lifecycle methods, and that work like big declarative catch blocks. With a bit of trickery, we can even make them report ridiculously usable error messages to an API of your choosing! Interested? Let's dive in!

As I mentioned, error boundaries are just regular components that implement a few special lifecycle hooks. The most important one is static getDerivedStateFromError. That method is called whenever a descendant component throws an error while rendering.

Note! Error boundaries doesn't catch errors in event handlers, async code or while doing server side rendering. Just a heads up!

Show me an error boundary!

An error boundary is just a simple component, really. Here's a very basic implementation:

The getDerivedStateFromError method receives an error, and returns the new diff in state. Basically like calling this.setState(diffInState), and very much the same like getDerivedStateFromProps. Makes sense?

The component up top shows its children if something cracks under pressure, and an error message.

You'd typically wrap it around the outer part of your application like this:

Note though - you can place this error component wherever you want. Facebook has this great example with Messenger - where they don't want to crash the entire application just because the input field for new messages crashes. You'd still like to see the messages, right? Fact is; you can wrap whatever you feel like! You can start with a global one up top, if you want, but consider creating more specialized ones downstream.

Logging frontend error

Dealing with front-end errors used to be a huge pain in the butt - and for many it still is. Luckily - with React - you can intercept these errors and do whatever you want with them!

As an example - let's post them to an API. We'll use the other special error lifecycle method, componentDidCatch, to handle side effects like logging.

With the componentDidCatch lifecycle method, we get two arguments - the error itself (an "undefined is not a function", perhaps?), and an info object, that contains a componentStack key - great for debugging errors in production.

Of course, you can use error reporting services like Sentry, or you can just create your own endpoint.

But, but... what if!

As mentioned earlier, some errors aren't caught by these error boundaries. How do we track those?

It turns out, the DOM has this amazing window.onerror error handler provided for us. You should probably attach that same error handler to this one as well, especially for error logging. So in your wrapping error boundary component - add that error listener as well:

That's it! Error handling and debugging has never been this simple ❤️

14-Dec

Today's posts

Content Security Policy

Writing JavaScript With Only Six Characters

Error Handling in React