If the CSS :visited leak warranted plugging at the browser level, so too should this. This is a pretty serious issue that's only going to easier to exploit once the :has() selector sees widespread support. Consider something like:
First possible solution that comes to my mind is implementing a new CSP directive to enable CSS attribute selectors that utilise a form element's value. Rationale: there are very few sane reasons to use the literal value of a form control as part of a CSS selector, especially with the plethora of various pseudo-classes indicating validity states, etc. Users with legitimate reasons to use value attribute selectors need only update their CSP.
(This might be overkill, but I'm convinced there's room in the web standard for plugging an exploit of this calibre).
Thanks for the note! Looking at the CSS rule, I think the current functionality of the plugin should block this, since at a core it's checking for an input and value assigned to it.
If the CSS
:visited
leak warranted plugging at the browser level, so too should this. This is a pretty serious issue that's only going to easier to exploit once the:has()
selector sees widespread support. Consider something like:First possible solution that comes to my mind is implementing a new CSP directive to enable CSS attribute selectors that utilise a form element's
value
. Rationale: there are very few sane reasons to use the literal value of a form control as part of a CSS selector, especially with the plethora of various pseudo-classes indicating validity states, etc. Users with legitimate reasons to usevalue
attribute selectors need only update their CSP.(This might be overkill, but I'm convinced there's room in the web standard for plugging an exploit of this calibre).
Thoughts?