Phoenix Blog Post: Content Security Policy configuration (in Phoenix with LiveView)

Learning Resources Blogs & Podcasts
, , ,
1

I had a bit of a mini-adventure following Sobelow’s advice on adding a CSP to a Phoenix App. If you want to follow along, or want to add a CSP to your own Phoenix App, then I wrote all about it here.

Posted via Devtalk (see this thread for details).

11 Likes
2

“When it comes to CSP, just about any policy is better than none” - Sobelow’s documentation

There’s a 2016 paper out of Google that found most sites CSP policies don’t work, https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45542.pdf

worth reading if you’re interested in the subject

2 Likes
3

Oh, thanks. I do find security things both fascinating and scary; sometimes I teeter on the edge of despairing that it’s all too complicated and one slip will make all the efforts pointless.

On first read I get

  • Don’t use Angular (kind of ironic from a Google paper)
  • Definitely steer clear of JSONP.
  • 'unsafe-inline' is bad. (Also unsafe-eval). The “unsafe” part is a bit of a hint.
  • Unsafe domains are a thing to consider, if I wanted to use 3rd party analytics or something. :thinking:
4 Likes
4

Nice manual! It fills the niche of “how to publish a CSP header in Phoenix”, while for other platforms Node.js, Wordpress, etc there is a lot articles.

It is only more correct to link to the official source Content Security Policy (CSP) - HTTP | MDN, since content-security-policy.com is an outdated site with incorrect information. For instance the wrong script-src 'nonce-r@nd0m' is shown right on the main page - the @ character is not allowed in the ‘nonce-value’.

The 2016 paper out of Google refered below is not actual.
In 2016 IE had 30% of the market but did not support CSP. Other browsers, except for Chrome, were supported CSP very poorly too.
Many third party javascript libraries required 'unsafe-inline' and some also required 'unsafe-eval'.
Popular site engines (CMS) also required rework in their scripts and styles.

Now things changed and Content Security Policy has become a de facto “must have” standard - every browser extension or web app must have it.

Security requirements have increased, Chrome extensions do not allow 'unsafe-inline' at all, Firefox extensions with a policy that use 'unsafe-eval' / 'unsafe-inline' keywords, allowing loading of external scripts and resources, as well as blob: files, are not allowed for extensions listed on addons.mozilla.org due to major security issues.

The situation is somewhat complicated by Safari browser, which is stuck at the CSP2 level.
Nonetheless all serious sites that work with personal data (Twitter, Facebook, Google, …) or money transfers (Paypal, etc.). have a CSP.

In addition to XSS attacks, CSP protects against ads substitution and injecting third-party ads, and prevents users from being tracked on the Internet.
So your article is very relevant for ordinary webmasters as well.

PS: To the principle “When it comes to CSP, just about any policy is better than none” from Sobelow’s documentation, I can add: “safety is never enough”.

3 Likes
5

Thanks! I’ve updated the post to link only to the MDN documentation.

6

Thanks for the fantastic article. It helped me fix a production bug where LiveView was refreshing every 10 or 15 seconds!

1 Like