Skip to content

[filter-effects-1] Document Clickjacking Attacks #13846

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
arichiv wants to merge 3 commits into
base: main
Choose a base branch
from
Open

[filter-effects-1] Document Clickjacking Attacks #13846

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e7217cd
[filter-effects-1] Document Clickjacking Attacks
arichiv Apr 28, 2026
85db8d8
Update Overview.bs
arichiv Apr 28, 2026
ebdf5ed
Clarify risks of SVG filters on cross-origin iframes
arichiv May 16, 2026
File filter

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion filter-effects-1/Overview.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3546,6 +3546,12 @@ If any of the above rules are not followed, an attacker could infer information

A timing attack is a method of obtaining information about content that is otherwise protected, based on studying the amount of time it takes for an operation to occur. If, for example, red pixels took longer to draw than green pixels, one might be able to reconstruct a rough image of the element being rendered, without ever having access to the content of the element. Security studies show that timing differences on arithmetic operations can be caused by the hardware architecture or compiler [[ArTD]].

<h3 id="clickjacking-attack">Clickjacking Attacks</h3>

Comment thread
arichiv marked this conversation as resolved.
User agents must not apply SVG reference <a element>filter</a>s to cross-origin/restricted iframes or web plugins because of their ability to arbitrarily manipulate pixels.

@Psychpsyo Psychpsyo May 27, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

What exactly does this mean?
If I set an SVG reference filter somewhere further up on the tree, so that it applies to some area of the page and the cross-origin frame within, does the filter as a whole become invalid? Or is it expected to leave only the iframe alone somehow and still apply to the content around it?

@arichiv arichiv May 27, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I think it's up to the user agent, though @progers may disagree. Assuming a setup like:

<div class="svg-filter">
  [...stuff...]
  <iframe src="remote origin"></iframe>
</div>

Ideally the 'stuff' still has the filter applied while the iframe does not, but if the design of the painter for the user agent precludes this somehow, it's better to fully invalidate the filter on all content than apply it to the iframe.

@Psychpsyo Psychpsyo Jun 25, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think the spec should at least be explicit with regards to the fact that this should apply to all reference filters that would/could end up using pixel data from the iframe. Otherwise, to a particularily lazy implementer, the interpretation of "only filters applied to the iframe directly" is on the table, which ends up negating all the intended security gains. Similarily, one might naively expect this to mean "all filters up the iframe's hierarchy", which is problematic as well, because of backdrop-filter.

I also worry that, if the details of this are left unspecified, it will lead to other browsers ultimately having to reverse-engineer Chrome once they get bug reports along the lines of "This backdrop filter on my modal isn't applying at all, but it works in Chrome."

Then again, I just tried that and Chrome 151 will still happily apply these filters to an iframe if done via backdrop-filter on an abspos element in front of the frame. So maybe it wouldn't be the worst idea for the spec to give some guidance here. WebKit and Gecko seem to get around this by just not applying the filter at all in that case. (In the regular filter case, they both manage to exempt only the iframe and not the rest of the page. Although in Gecko, the iframe does turn solid white.)
If this is permitted, it allows the manipulation of otherwise inaccessable frames, potentially causing users to take actions they might not otherwise.
See the Clickjacking section of <a href="https://html.spec.whatwg.org/multipage/introduction.html#writing-secure-applications-with-html">HTML Spec</a>.

<h2 id=security>Security Considerations</h2>

Besides the security implications of the privacy issues noted above,
Expand Down Expand Up @@ -3628,4 +3634,4 @@ effect-reference-merge-no-inputs.tentative.html
filter-region-negative-positioned-child-001.html
effect-reference-displacement-negative-scale-001.html
backdrop-filters-grayscale-001.html
</wpt>
</wpt>