Skip to content
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions docs/guide/features.md
Original file line number Diff line number Diff line change
Expand Up @@ -774,6 +774,15 @@ The nonce value of a meta tag with `property="csp-nonce"` will be used by Vite w
Ensure that you replace the placeholder with a unique value for each request. This is important to prevent bypassing a resource's policy, which can otherwise be easily done.
:::

:::tip Limitations in SPA deployments
When deploying as a Single Page Application (SPA), be aware that the nonce value is only set in the initial HTML.
Because navigation in an SPA does not reload the HTML document, the nonce meta tag will not be refreshed on
subsequent requests. This means that enforcing CSP with nonces in a pure SPA deployment is not fully reliable.
Comment on lines +779 to +780
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the nonce meta tag will not be refreshed on subsequent requests. This means that enforcing CSP with nonces in a pure SPA deployment is not fully reliable.

Why does the nonce meta tag need to be refreshed on SPA navigations? The spec only says "If a server delivers a nonce-source expression as part of a policy, the server MUST generate a unique value each time it transmits a policy.". SPA navigations will not cause the server to re-send the policy. The spec does not say that the nonce should be re-generated for SPA navigations.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing that out 🙏 You're right, the spec requires the server to generate a new nonce on each response. My concern here is that in SPA deployments, after the initial response, subsequent navigations do not trigger new HTML responses, so scripts injected later (or dynamically created) cannot rely on a fresh nonce.

I’ll rephrase the note to make this clearer: it’s not that the spec requires re-generation on SPA navigations, but rather that SPAs don’t naturally provide new nonces after the initial load, which can weaken CSP enforcement in practice.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

scripts injected later (or dynamically created) cannot rely on a fresh nonce.

I don't find that to be a problem. Would you elaborate on why this is a problem and would weaken CSP enforcement?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, fair point. To clarify: not getting a fresh nonce on SPA navigations is not a spec violation and isn’t a problem by itself. The issue is operational: after the initial load, any scripts you create at runtime must either (a) carry the current document’s nonce or (b) be allowed via strict-dynamic from a trusted bootstrap script. If a team doesn’t do one of these, they often relax the policy ('unsafe-inline', broad sources, etc.) to make runtime scripts work, that is what weakens enforcement in practice.

I’ll reword the note to reflect this: SPAs don’t rotate the nonce automatically, make sure to propagate the nonce (or use strict-dynamic). When you need per-navigation rotation or policy changes, serve a fresh HTML response (SSR or MPA).

I’ll update the doc text accordingly. 🙏

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

after the initial load, any scripts you create at runtime must either ...

I don't think this is specific to SPAs. script tags can be injected in non-SPA sites.

If a team doesn’t do one of these, they often relax the policy ('unsafe-inline', broad sources, etc.) to make runtime scripts work, that is what weakens enforcement in practice.

Well, that's not something specific to Vite. We can link to a high quality article like https://web.dev/articles/strict-csp, but we should focus on Vite specific things in the document.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks 🙏 That makes sense. You're right, the CSP concerns about runtime script injection are not SPA-specific, and it's better to keep the Vite docs focused. I’ll simplify the note to highlight the limitation in SPAs and link out to the strict CSP article for further guidance.


For stronger guarantees, prefer using SSR or serving fresh HTML responses per request so that a new nonce
can be injected dynamically.
:::

### [`data:`](<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/Sources#scheme-source:~:text=schemes%20(not%20recommended).-,data%3A,-Allows%20data%3A>)

By default, during build, Vite inlines small assets as data URIs. Allowing `data:` for related directives (e.g. [`img-src`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/img-src), [`font-src`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/font-src)), or, disabling it by setting [`build.assetsInlineLimit: 0`](/config/build-options#build-assetsinlinelimit) is necessary.
Expand Down