fix: hash generation missing for link as script about nuxt-security HOT 21 CLOSED

A static build yields in firefox:

Mentioning those head links:

from nuxt-security.

Right, this is because we set hashScripts : true by default 🤯
So what you are seeing are the hashes for the inline scripts. In your case, CSP is blocking the external scripts, hence the requirement for ’self’ 🤯🤯

from nuxt-security.

Maybe this is the right moment to mention the discussion in #258. I imagine other modules, let's take nuxt-gtag for example, to use a hook provided by nuxt-security to add the headers they require automatically for the user. So a user is not required to ever see things like connect-src: https://*.analytics.google.com 🌈 (but could of course if they chose to)

from nuxt-security.

Hey @vejja @dargmuesli

I would vote for the secure one. Users tend to use this module to have opinionated and secure approach in their apps. And if the default one does not work for them, they can always modify and customize it to match their needs

from nuxt-security.

Hey @vejja @dargmuesli

I would vote for the secure one. Users tend to use this module to have opinionated and secure approach in their apps. And if the default one does not work for them, they can always modify and customize it to match their needs

ok, I'll submit a PR that modifies the default config to reflect this

from nuxt-security.

Hey,

I am not sure if that is actually possible.

@vejja do you have any experience with such approach?

from nuxt-security.

Generally speaking, CSP says that for external scripts the hash must be provided via the integrity attribute. It is the responsibility of the user to provide it, as Nuxt Security cannot give an opinion on whether or not the referenced script is legit.

@dargmuesli is right that we are only parsing <script> and not <link>.
I don't think CSP requires that links should also be checked via integrity hashing (I'm not sure browsers implement this, would need to check in details).
I cannot see any fundamental problem though with adding more hashes to the policies, other than polluting the headers with incompressible strings and increasing network load a bit. We could definitely do it.

But are you sure that CSP is blocking a link ?
What is the rel attribute of your link ? Is it preload ?

from nuxt-security.

Yes, I have rel=preload, =modulepreload and =prefetch in my html's head.

from nuxt-security.

That could definitely make sense, although I suspect prefetch could get blocked by connect-src

The new feature can easily be implemented once we determine the scope of the rel attributes that we need to cover.
Would you mind sharing a repro if possible? It would be extremely helpful to do this work

Edit: Also if you don't mind sharing your nuxt config. Would like to know whether you are using ssr: false and script-src 'strict-dynamic', amongst others

from nuxt-security.

Sure! I do most of my testing / update regression checks on https://github.com/dargmuesli/vio.

Here is a reproduction, including instructions: https://stackblitz.com/edit/github-ljxjtg?file=app.vue

from nuxt-security.

Sure! I do most of my testing / update regression checks on https://github.com/dargmuesli/vio.

Here is a reproduction, including instructions: https://stackblitz.com/edit/github-ljxjtg?file=app.vue

Ok I can see now what happens. You have "script-src": [] which means no external script can run, so all of your Nuxt root scripts are being denied
If you set "script-src": ["'self'"] you should be OK.

I will still submit a PR for your use case which stays valid.
A user can expect to have its application running properly by default.

@Baroshem: We still need to decide what is by default

1- Either we think that a strict CSP should not be enforced by default. In that case we default to "script-src": ["'self'", "'unsafe-inline'", "https:"], nonce:false, and hashScripts: false, which is insecure but will work in all cases.

2- Or we think that a strict CSP should be enforced by default. In that case we default to "script-src": ["'strict-dynamic'", "'nonce-{{nonce}}'"] , nonce: true and ssg: hashScripts: true, which is secure but will need PR #285 to be merged first so that we can also set sri: true.
WDYT ?

from nuxt-security.

Notice that when the stackblitz is built statically and started served, the script-src is not empty:
content="base-uri 'none'; font-src ; form-action 'none'; img-src ; object-src ; style-src 'self'; child-src ; connect-src 'self'; default-src 'none'; frame-src ; media-src ; navigate-to ; report-to ; script-src 'sha256-G4xesWpEl5pvvC/7y77ggtKRwumKacySurlAfZ9Hx/E=' 'sha256-jbA90S2W5VDKndRn6oTVtKuEQsc4kcRRCSdutkAFYOQ='; worker-src "

Two hashes are added, but not one for <link rel="prefetch" as="script" crossorigin="" href="/_nuxt/error-500.91725575.js">.

from nuxt-security.

@Baroshem expanding on the discussion above:

I kindly believe, IMHO, that setting up CSP is way to complicated as it stands currently.
There are too many parameters that need to be set up simultaneously for our users.

I know that backwards compatibility is a requirement.

In that case, why don’t we provide a Boolean option where we setup the right CSP parameters ourselves?

• if the user chooses to use CSP, we do all the hardwiring of nonce, hashes, strict-dynamic, ssg, scripts, styles, sri, placeholders etc. ourselves in the background
• If the user chooses not to use CSP, we default to an unsafe setup that works

in both cases we can still keep the existing interface for advanced users who want to customize their policies

the new option would just be a convenience shortcut that sets sensible defaults for most people

we could call that a cspPreset and it could have 2 possible values: ‘strict’ and ‘unsafe’

Let me know what you think

from nuxt-security.

Maybe this is the right moment to mention the discussion in #258. I imagine other modules, let's take nuxt-gtag for example, to use a hook provided by nuxt-security to add the headers they require automatically for the user. So a user is not required to ever see things like connect-src: https://*.analytics.google.com 🌈 (but could of course if they chose to)

This sounds like an excellent option to me.
In this sense, a cspPreset would just be a customized invocation of that generic hook

from nuxt-security.

@vejja @dargmuesli I noticed that a PR was referenced here but I am not sure if it was supposed to fix this issue or it was just as an insight to future implementation?

from nuxt-security.

PR #287 fixes issue #279: we now parse links on top of scripts
But it would still be good to have your feedback on presets/how to simplify CSP setup

from nuxt-security.

Thanks for the clarification @vejja !

Regarding presets. To be honest I am not really into that idea. I cant think of what presets we could create as in terms of CSP it is usually very individual on what user might need to work on their application (i.e he is using certain external script that he wants to allow using)

However, we could export default module configuration object and allow user to import this default config and just extract some properties that he needs (for example csp) and later use it in their code with just overriding the default values. But this on the other hand can be achieved right now with the usage of defu.

Not so sure about it. Do you guys maybe have some ideas on how this could work (with a use case scenario)?

from nuxt-security.

@Baroshem
What I’m trying to say is there are only 2 valid combinations that I can think of :
1- script-src self unsafe-inline https: strict-dynamic nonce-{{nonce}} + style-src self unsafe-inline https: + ssg.hashScripts true + ssg.hashStyles false + nonce true + sri true
2- script-src self unsafe-inline https: + style-src self unsafe-inline https: + ssg.hasScripts false + ssg.hashStyles false + nonce false

Any other combination will block a Nuxt app.
For instance our default options will block rendering.

For clarity I am totally for letting the user customize all these options at will depending on use cases. And as you say, anyone should be able to defu anything freely

But I believe we need to provide defaults that don’t block

from nuxt-security.

Those defaults concern development? Or SSR and SSG as well? For my applications I have some lax CSP for development, e.g. access to Nuxt's dev server HMR websockets, and stricter CSP for production. Also a static deployment may not need the same CSP as a SSR deployment.

from nuxt-security.

Those defaults are for everything (dev, ssg, ssr)

Of course I simplified a bit by only mentioning the script-src and style-src directives, which are the tricky ones. The other directives are not problematic usually.

The first variant is a strict CSP setup. The second one is an unsafe setup.

from nuxt-security.

Released with 1.0.0-rc.4 :)

from nuxt-security.