v150 · security · rendering

SVG Filter Policy Tester

Tests which iframe configurations allow SVG filters in Chrome 150. Six configurations ranging from same-origin to fully sandboxed. For each, inject an SVG <feColorMatrix> filter and observe whether it applies, see the policy rule that governs the decision, and the recommended workaround.

Detecting browser…

Policy summary — Chrome 150

Configuration CSS shorthand filter SVG url(#id) filter Chrome 150 policy
Same-origin iframe allowed allowed No restriction — same origin means caller can read the content anyway
Cross-origin + CORS allowed blocked CORS does not grant pixel-read access. SVG filter blocked at origin boundary.
Cross-origin, no CORS allowed blocked Same as above — SVG filter cannot cross origin boundary regardless of CORS.
Sandboxed (same-origin) allowed blocked sandbox attribute creates a restricted browsing context — SVG filters blocked even for same-origin content when sandboxed.
Cross-origin sandboxed allowed blocked Both cross-origin and sandboxed restrictions apply. Double boundary.
Sandboxed + allow-same-origin allowed blocked allow-same-origin restores same-origin context but does not lift the SVG filter restriction introduced in Chrome 150.

SVG filters like <feColorMatrix> and <feDisplacementMap> operate on the rendered pixels of whatever they cover. When a cross-origin iframe is inside a filtered container, the filter samples the iframe's pixel data — including text and images the embedding page should never be able to read.

Attacker page
evil.example
→
SVG filter wrapper
filter: url(#extract)
↓
Embedded iframe
bank.example (cross-origin)
↓
feDisplacementMap
shifts pixels to reveal content

The lyra.horse demonstration in 2024 showed how a feDisplacementMap aimed at an embedded bank login form could pixel-shift the form enough to make a fraudulent overlay match pixel-perfectly — enabling clickjacking that bypasses visual inspection.

Chrome 150 blocks all SVG filter effects that would cross the origin boundary of any iframe or plugin content. The renderer walks up the effect tree and strips the filter before painting restricted content. CSS shorthand filters (blur(), brightness(), grayscale(), etc.) that do not enable pixel-level manipulation are unaffected.

Recommended workarounds

Use CSS shorthand filters — filter: blur(4px), filter: grayscale(1), filter: brightness(0.5) etc. are still allowed on cross-origin iframes because they cannot be used to extract pixel data.
Apply SVG filters to same-origin content only — If you need a complex SVG filter effect, apply it to elements that are same-origin with the embedding page. SVG filters on same-origin iframes are still allowed.
Proxy the content — If your server can fetch and serve the third-party content as same-origin (with appropriate caching and security headers), SVG filters can be applied. This only makes sense when you control both ends.
Use CSS backdrop-filter — Applies visual effects behind an element (not to its content). Does not sample cross-origin pixel data and is not affected by this restriction.

see also