Move "image masks" to variables

[envygeeks]

Currently, in an imperfect world, DaisyUI applies image masks using inline SVG, which creates significant complications when enforcing a strict Content Security Policy (CSP). Specifically, by default, DaisyUI forces developers to either loosen their CSP via img-src 'self' 'nonce-<Redacted>' data:; or forgo using masks entirely—both of which are unideal.

Proposed Solution

A more robust and CSP-friendly approach would be to move all mask definitions to CSS custom properties, similar to how --fx-noise is handled via --mask-example: url('data:'); as this would allow us to override with:

:root {
  --mask-example: url(/assets/masks/example.svg);
}

At this point we can apply a strict CSP:

content-security-policy:
  base-uri 'none';
  default-src 'self';
  connect-src 'self' 'nonce-<Redacted>';
  font-src 'self';
  form-action 'self';
  frame-ancestors 'self';
  frame-src 'self';
  img-src 'self' 'nonce-<Redacted>';
  manifest-src 'self';
  media-src 'self';
  object-src 'none';
  script-src-attr 'none';
  style-src 
    'self' 
    'nonce-<Redacted>' 
    'unsafe-hashes'
      'sha256-<Redacted>'
      'sha256-<Redacted>'
      'sha256-<Redacted>'
      'sha256-<Redacted>'
      'sha256-<Redacted>'
      'sha256-<Redacted>;
  script-src 
    'self' 
    'strict-dynamic' 
    'nonce-<Redacted>';
  upgrade-insecure-requests;
  worker-src 'self';

Why It Matters

• ✅ Maintains strict CSP enforcement
• ✅ Aligns with existing conventions (e.g., --fx-noise)
• ✅ Avoids reliance on unsafe data: sources
• ✅ Improves developer flexibility

Refactoring DaisyUI’s mask system to use var(--mask-name) and externally referenceable assets would significantly improve security compliance, DevEx, and even customization.

🚨 Why data: in CSP is a Security Risk

The data: URI scheme allows developers to embed small files (like images, fonts, scripts, or styles) directly into the document as base64 strings. While convenient, allowing data: in your CSP (e.g., img-src 'self' data:) can open the door to subtle yet serious exfiltration attacks. I should note, some browsers do attempt to stop this kind of tomfoolery however, that doesn't mean we shouldn't still enforce strict CSP.

MDN: Content-Security-Policy XSS
Is including the data scheme in your Content Security Policy safe?
Content Security Policy Cheat Sheet

[saadeghi]

How is it a security risk when the SVG code is in your own CSS file? 🤔
Isn't it the opposite of what your suggesting? Loading a file from external URL creates a security risk.

[envygeeks]

Technically it's not in my own CSS file. It's provided by you the author of DaisyUI which makes it high risk unless I audit every update. You're right that external SVGs can be risky, but what's often overlooked is that embedding SVGs inline via data: URIs introduces an even higher risk—especially in environments enforcing strong CSP. When you embed an SVG with data:image/svg+xml;base64,..., it:

• Inherits your origin
• Bypasses many CSP protections
• Can contain active content, like:
  • <script>
  • <foreignObject> with HTML
• Becomes a vector for XSS and data exfiltration

---

If you serve your SVG from a same-origin path like /assets/mask.svg and use:

img-src 'self';

Then you gain:

• CSP enforcement
• MIME-type control via headers like:
  • Content-Type: image/svg+xml
  • X-Content-Type-Options: nosniff
• The ability to lock it down further with CSP like:

default-src 'none';
script-src 'none';
style-src 'none';
object-src 'none';
connect-src 'none';
base-uri 'none';
img-src 'none';

---

🧠 TL;DR

Embedding Method	Risk Level	Notes
data: URI	🔥 High	Inherits origin, hard to constrain
External URL (same-origin)	✅ Lower	Easier to CSP-lock and audit
3rd-party SVG	🔥 High	Should always be distrusted

So yes—external SVGs from untrusted sources are dangerous, but embedding them inline using data: is often worse. It's not just "internal vs. external"—it's about execution context and enforceable boundaries.

[saadeghi]

Thanks for the details but I still don't understand how CSS variables can help with security here...

Technically it's not in my own CSS file. It's provided by you the author of DaisyUI which makes it high risk unless I audit every update.

Right now there are embedded SVG masks inside the CSS.

Imaginary scenario of a attack:

😈 Imagine daisyUI goes evil and puts a harmful SVG code instead of the current SVG and that would be a security issue indeed.
🥸 Even if the current SVGs are CSS variables that you customize and serve those files from your own URLs, that evil update can still add a NEW harmful SVG that you didn't expect.

So I don't think using CSS variables would help with this concern.

I think what would work for your concern is to lock the package version to prevent automatic NPM updates. Not just for daisyUI, but any packages (especially JS packages which is even easier for them to inject a harmful code in an imaginary scenario)

[envygeeks]

Locking the package version doesn't help because you have to add data: to the CSP, that creates the security issues every where all at once. I guess I could customize the response headers, but that doesn't really prevent the issue in full. Using a variable certainly helps, because Nuxt, Vite, Tailwind and PostCSS will replace your source when I do something like I did with .btn

:root {
  --fx-noise: url(
    /assets/noise.svg
  );
}

You can see that in action at https://envygeeks.io and even the strict headers that I use