How to handle content security policy (CSP) in a Vue SPA?

Avoid inline scripts and styles by moving all JavaScript to external files and using Vue’s event handlers instead of inline onclick attributes. 2. Use a strict CSP header without 'unsafe-inline' or 'unsafe-eval' by adopting Vue’s runtime-only build and Single File Components to eliminate the need for dynamic template compilation. 3. Handle dynamic content safely with v-html only after sanitizing user input using DOMPurify, ensuring CSP blocks script execution in injected HTML. 4. If inline scripts are necessary, use nonces or hashes instead of 'unsafe-inline', though this is best avoided in static SPAs unless using SSR. 5. Allow external resources like CDNs by explicitly specifying domains in CSP directives such as script-src, img-src, font-src, and connect-src, while avoiding 'unsafe-inline' for styles by using external or scoped CSS. 6. Test your CSP using browser dev tools, Google CSP Evaluator, and report-only mode to detect violations without enforcement, ensuring all policies work as intended before full deployment. By following these steps, a Vue SPA can operate under a strict Content Security Policy that effectively mitigates XSS and code injection risks without relying on unsafe directives, resulting in a secure and maintainable application.

Handling Content Security Policy (CSP) in a Vue Single Page Application (SPA) is essential for securing your app against XSS (cross-site scripting) and other code injection attacks. However, Vue SPAs — especially those using dynamic features like inline scripts, eval(), or v-html — can easily conflict with strict CSP rules. Here’s how to handle CSP properly in a Vue SPA.

✅ 1. Avoid inline scripts and styles

CSP blocks inline <script></script> and <style></style> tags by default. Vue itself doesn’t generate inline scripts when built properly, but common patterns can break CSP:

• Avoid inline event handlers (@click, v-on) in templates — these are generally fine because Vue compiles them into event listeners, not inline onclick="".
• Don’t use inline <script></script> tags in your index.html. Move all logic to external files.

❌ Bad (violates default CSP):

<!-- index.html -->
<script>
  console.log('init');
</script>

✅ Good:

<!-- index.html -->
<script src="js/app.js"></script>

Use Webpack/Vite to bundle your Vue app and externalize all JavaScript.

✅ 2. Use a strict CSP header (without 'unsafe-inline')

When deploying, set a strong CSP via HTTP headers (preferred) or <meta http-equiv="Content-Security-Policy">.

Example CSP header for a Vue SPA (hosted on same origin):

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'unsafe-eval' 'unsafe-inline';  ← Avoid this!

Wait — you see 'unsafe-eval' and 'unsafe-inline'? That’s common during development but insecure.

Fix 'unsafe-eval'

Vue’s runtime compiler (template compilation in browser) uses new Function(), which triggers 'unsafe-eval'. To remove this:

➡️ Use the runtime-only build of Vue

In your Vue project (Vue 3 with Vite or Webpack), ensure you're using the runtime-only version:

// vite.config.js or webpack config
resolve: {
  alias: {
    'vue': 'vue/dist/vue.runtime.esm-bundler.js'
  }
}

And write your components using .vue files with <template>, not runtime templates like:

app.component('my-comp', { template: '<div>hi</div>' }) // needs compiler → needs unsafe-eval

✅ Instead, use SFCs (Single File Components):

<!-- MyComponent.vue -->
<template>
  <div>Hi</div>
</template>
<script>
export default {}
</script>

Now you can remove 'unsafe-eval' from script-src.

✅ 3. Handle dynamic content safely

Vue’s v-html directive can be dangerous and may require 'unsafe-inline' if misused.

❌ Avoid:

<div v-html="userContent"></div>

This opens XSS risks and doesn’t help CSP — CSP can’t distinguish safe vs unsafe v-html.

✅ Safer approach:

• Sanitize user content with libraries like DOMPurify:

import DOMPurify from 'dompurify';

const cleanHTML = DOMPurify.sanitize(userHTML);

<div v-html="cleanHTML"></div>

Still, v-html doesn’t require relaxing CSP if you're not injecting inline scripts. CSP will block script execution in v-html content — which is good.

So: v-html is acceptable if you sanitize input and your CSP blocks script execution from DOM.

✅ 4. Use nonces or hashes for allowed scripts (if needed)

If you must include a safe inline script (e.g., early init code), use nonces or hashes instead of 'unsafe-inline'.

Example with nonce:

Generate a unique nonce per request on the server:

Content-Security-Policy: script-src 'self' 'nonce-abc123'

Then:

<script nonce="abc123">
  // small inline script
</script>

⚠️ This requires server-side rendering (SSR) or dynamic HTML generation. In a static Vue SPA, this is hard to implement unless you use SSR (Nuxt, etc.).

Alternatively, avoid inline scripts entirely — better for CSP and maintainability.

✅ 5. External resources and CDNs

If your Vue app loads external assets (fonts, analytics, APIs), update CSP accordingly.

Example:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.m.sbmmt.com;
  img-src 'self' https://*.m.sbmmt.com;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://api.yourservice.com;
  style-src 'self' 'unsafe-inline'; ← minimize use

➡️ Avoid 'unsafe-inline' for style-src by:

• Moving all CSS to external files (Vue handles this via scoped styles or CSS extraction).
• Using style-src 'self' if all styles are bundled.

✅ 6. Test your CSP

Use browser dev tools (Security tab) to check CSP violations.

Also use:

• Google CSP Evaluator
• Report-only mode:

  Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint

  This logs violations without blocking, great for testing.

  ---

  Summary: Best Practices

  • ✅ Use runtime-only Vue build to avoid 'unsafe-eval'
  • ✅ Avoid inline scripts/styles in index.html
  • ✅ Sanitize v-html content with DOMPurify
  • ✅ Use external bundles (Vite/Webpack) for all JS/CSS
  • ✅ Set CSP via HTTP headers: script-src 'self', no 'unsafe-inline' or 'unsafe-eval'
  • ✅ Allow only necessary external domains
  • ✅ Test CSP with Report-Only and browser tools

  ---

  Basically, with proper Vue setup and deployment hygiene, you can run a Vue SPA under a strict CSP — no unsafe flags needed. It just takes attention to how and where code is loaded.

  The above is the detailed content of How to handle content security policy (CSP) in a Vue SPA?. For more information, please follow other related articles on the PHP Chinese website!