Move "image masks" to variables #3958
Replies: 3 comments 1 reply
-
How is it a security risk when the SVG code is in your own CSS file? 🤔 |
Beta Was this translation helpful? Give feedback.
-
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
If you serve your SVG from a same-origin path like
Then you gain:
🧠 TL;DR
So yes—external SVGs from untrusted sources are dangerous, but embedding them inline using |
Beta Was this translation helpful? Give feedback.
-
Thanks for the details but I still don't understand how CSS variables can help with security here...
Right now there are embedded SVG masks inside the CSS. Imaginary scenario of a attack:
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) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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:At this point we can apply a strict CSP:
Why It Matters
--fx-noise
)data:
sourcesRefactoring 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 RiskThe
data:
URI scheme allows developers to embed small files (like images, fonts, scripts, or styles) directly into the document as base64 strings. While convenient, allowingdata:
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
Beta Was this translation helpful? Give feedback.
All reactions