Content Security Policy applied to Single Page Applications: Is it worth it with unsafe-inline?

Question

I have a website developed using VueJS (i.e. its a single page application). I've been looking at implementing Content Security Policy headers. As I tested out the header values I would need, I realised I would have to allow 'unsafe-inline' scripts, as this is fundamentally what my website is.

I've read around this a fair bit and found plenty of comments indicating that if I need to apply 'unsafe-inline', the CSP header really isn't going to do much for me.

So my question is; does applying 'unsafe-inline' render CSP more or less pointless? Does anyone have any good ideas of how to handle CSP on an SPA?

Answer 1

does applying 'unsafe-inline' render CSP more or less pointless?

Preventing XSS is one of the main benefits of a CSP. If you need to allow inline scripts, that benefit is mostly gone.

But there are still some situations where a CSP can prevent exploitation of issues. Examples:

• Clickjacking: a CSP can prevent it
• HTML injection: Even if no XSS can be gained, HTML injections can be used to exfiltrate data. A CSP may be able to mitigate some of the impact (by restricting form actions, images sources, etc)
• CSS injection: If you don't have inline CSS, you can prevent CSS injection via CSP
• even with unsafe-inline, a CSP may make XSS more difficult to exploit. The easiest way to exploit XSS is to include a remote script, as an attacker doesn't have to worry about length or special character restrictions in the payload
• enforce content to be loaded via HTTPS

Does anyone have any good ideas of how to handle CSP on an SPA?

The same way as with any application: Don't have inline scripts. Instead, you should have all your scripts in .js files, which you then include from a trusted origin (this actually seems easier to achieve in a SPA compared to a classic application which may have inline JavaScript all over the place).

You can also allow a specific script block using a nonce or hash source (which implemented correctly prevents XSS).

Even if you need to allow unsafe-inline for now, I'd still recommend implementing a CSP which is as restrictive as possible given the situation.

It will help you implement future features in a way compatible with a restrictive CSP. And when you get around to removing inline js, you just need to remove unsafe-inline from the CSP that you have in place already (instead of having multiple issues to worry about implementing a new CSP).

Answer 2

I've read around this a fair bit and found plenty of comments indicating that if I need to apply 'unsafe-inline', the CSP header really isn't going to do much for me.So my question is; does applying 'unsafe-inline' render CSP more or less pointless?

True, Disallowing inline styles and inline scripts is one of the biggest security wins CSP provides. However, if you absolutely have to use it, there are a few mechanisms that will allow them. You can use a nonce-source to only allow specific inline script blocks:

Content-Security-Policy: script-src 'nonce-2726c7f26c'

You will have to set the same nonce on the element:

<script nonce="2726c7f26c">
  var inline = 1;
</script>

Does anyone have any good ideas of how to handle CSP on an SPA?

Hopefully this may help(change xx to tt): hxxps://developer.squareup.com/blog/content-security-policy-for-single-page-web-apps/

Credits: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src

Answer 3

Yes, it is worth setting up a CSP anyway. Here are a few benefits:

• Many real world XSS vulnerabilities does not allow arbitrarily long payloads. A common technique is then to just have a small payload that loads the big payload from another server. This can be prevented with a CSP.
• You can prevent clickjacking with a frame-ancestors directive.
• There are other useful things you might want to set, such as object-src. MDN has a nice list.

But you are right that the biggest benefit is to be able to block unsafe-inline. I think this should be possible to accomplish with Vue.JS without to much work.

So if you can find a way to get rid of unsafe-inline, it would be good. But something is still better than nothing.

Answer 4

An XSS attack has two phases.

1. Get the script into the web page (Attack vector)
2. Do something malicious that benefit the attack (Payload)

While unsafe-inline makes the attack vector much easier it can still block many payloads if it's set up correctly.

• It will block reporting back any data to a control server or similar. Making it hard to steal data.
• It will block injecting more scripts into the page.

There are still possible payloads. But generally they would have to abuse the internal API's somehow if the rest of the CSP is set up strict enough.