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
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).