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

14 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

3 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:
6 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”.

4 Likes
5

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

1 Like
6

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

1 Like
7

Hey, great article!

A couple of notes I found when implementing it to my phoenix LiveView webapp that could help to those who want to also implement this.

When compiling the final snippet I got the following warning: warning: Application.fetch_env!/2 is discouraged in the module body, use Application.compile_env/3 instead

Where I replaced the fetch env line for:

@host Application.compile_env(:example, [ExampleWeb.Endpoint, :url, :host], "localhost")

Also the last snippet where the "font-src data:;" is added seems to be missing a <> at the end of the line above

Other than that it seems to be working great and I totally agree that it is best to not ignore advice from security experts!

Edit: typo.

8

Thanks. This post predates Compile.env/3 and I’ve been meaning to update it.

It really should be getting the host at runtime these days, rather than compiling in, as that is by default now set in `runtime.exs.