Content Security Policy (CSP) with next.js

[dbo]

Edit: This issue is very old and has now been replaced with #23993.

---

I don't see a way using next.js with a sensible CSP employed, foremost because it's eval'ing the component code (unsafe-eval is highly discouraged w.r.t. XSS). In addition, the injected scripts page component scripts should get a computed hash, and an SRI hash should be added for the CDN/next.js script.

Excuse my ignorance about, but wouldn't it be better to use plain old script tag loading for the component module, props etc.?

[nkzawa]

I'm not familiar with CSP, but it seems next.js doesn't support CSP at all for now.
eval is used just because it's a more flexible way to execute codes compared to others.

[arunoda]

CSP is kind a standard for web security and usually we disable eval with CSP. (and similar functionalities)
As a fix for this, we might need to load the page bundle as a JavaScript. Usually, loading scripts from the same domain is allowed with CSP. So, that won't be an issue.

---

That's being said, stored XSS is not possible with React unless you use dangerouslySetInnerHTML.

So, we are not in a huge security risk.

[arunoda]

@dbo about this:

In addition, the injected scripts page component scripts should get a computed hash, and an SRI hash should be added for the CDN/next.js script.

I hope this is about another issue.
Shall we open a new issue for that?

[dbo]

@arunoda IMHO this is a blocker to seriously deploy next.js apps; CSP is a standard, eval discouraged. Avoiding dangerouslySetInnerHTML in your code is common practice, but what about 3rd party NPMs, e.g. older template engines. You'd have to audit all of your dependencies.

Regarding your latter question: I think this task should be about getting next.js running with strict CSP, i.e. preferably the hashes for the inline script as well as a SRI hash for the CDN-script could be generated (at build time?), so no need to allow any inline-script, CDN script-src.

[rauchg]

@dbo just so I understand the attack surface better: why would you use a template engine in this context?

[dbo]

As I've written, my primary code can (and should) avoid dangerouslySetInnerHTML and also doesn't need a templating engine, since it's react. But any 3rd party NPM (and transitive dependencies) that I use might do so, especially any 3rd party react component might use dangerouslySetInnerHTML.

Also look at this from a different angle: Any serious customer would require you to do a security audit/proof of the site you've built. Given a decent browser baseline, it's much easier and less effort to do that in context of a CSP.

[rauchg]

Definitely. I'll keep this open. Consider this approach:
#253 (comment)

The problem is that it introduces a new roundtrip, however.

[dbo]

@rauchg reads sensible
@nkzawa To be honest, I consider this a major blocker for any production site. So this doesn't sound like an enhancement to me.

[rauchg]

What you're saying is that you want a protection from yourself (unaudited code that you might include in your own codebase). That by definition is a security enhancement, not a hole.

I think this is important to address, and we're thinking about how to best do it without a tradeoff in performance.

[dbo]

@rauchg Of course this is not about a security hole, but a very important security enhancement, it's highly recommended and standardised practice for good reason.
Regarding your point of "protection from yourself", please keep in mind that a lot of developers simply don't have

• the time
• the experience

to thoroughly audit all of their transitive dependencies. I simply don't expect it to happen.

[rauchg]

Absolutely. Was just pointing out that @nkzawa picked the right label, and
that we consider it very important still.

On Tue, Nov 22, 2016 at 9:53 AM ǝlzlǝoq lǝᴉuɐp ツ notifications@github.com
wrote:

@rauchg https://github.com/rauchg Of course this is not about a
security hole, but a very important security enhancement, it's highly
recommended and standardised practice for good reason.
Regarding your point of "protection from yourself", please keep in mind
that a lot of developers simply don't have

• the time
• the experience
  to thoroughly audit all of their transitive dependencies. I simply
  don't expect it to happen.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#256 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAy8Q8YhTOBrwAaIk-XR9x9iSbGkZHQks5rAx4hgaJpZM4Kx9aI
.

[aesopwolf]

CSP headers are definitely a high priority in my opinion. However, it's possible to use a meta tag as an alternative for the time being.

https://developers.google.com/web/fundamentals/security/csp/#the_meta_tag

[dbo]

@aesopwolf Using a meta tag as an alternative to HTTP headers is not the issue here, it will prevent the page from working, too, unless you allow unsafe-eval.

[aesopwolf]

@dbo my apologies, I skimmed over the thread too fast.

@rauchg Is there anything we can do to help fast-lane the SRI hash for the CDN script? My company is in the final phases of a new registration app built on next.js and we expect to see 150k signups in January so having the CDN would definitely be nice to have.