[wp-trac] [WordPress Trac] #61501: KSES Allow more custom data attributes to align with browsers

[WordPress Trac]

#61501: KSES Allow more custom data attributes to align with browsers
--------------------------------------+-----------------------
 Reporter:  jonsurrell                |       Owner:  dmsnell
     Type:  enhancement               |      Status:  assigned
 Priority:  normal                    |   Milestone:  7.0
Component:  Formatting                |     Version:  6.6
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-----------------------

Comment (by dmsnell):

 @wildworks the rest of this is good for 7.0 — thank you. @peterwilsoncc
 @jorbin sorry I wasn’t able to get the audit in in time.

 one idea I have for this is whether we should consider something a bit
 coarse as a first step:
  - reject storing URL values, including those with `javascript:` or
 `data:` schemes unless explicitly allowed by the filter.
  - allow everything else.

 I did do some brief scanning for existing JS code using custom data
 attributes to set properties but realized it’s a much harder search than I
 expected. I’m really tempted to propose again that we simply allow all of
 them because ultimately it’s the responsibility of the JS code to escape
 content it writes into JS attributes.

 when I try to think of potential abuses I’m struggling to figure out how
 we could tell the difference between intention or accident or malice and I
 may just not be in tune enough with this avenue. it seems like we either
 have complete risk allowing //any// custom data attributes on save, or the
 only way to eliminate that risk is to disallow //all// custom data
 attributes on save.

 but it’s really //save// vs. rendering code I guess, because, for example,
 the Interactivity API is going to want to set these and I’m guessing that
 dynamically-rendered code will pass through `wp_kses_post()` at some
 point, probably accidentally, and things will break if not referencing one
 of the explicitly-allowed custom data attributes.

 would appreciate anyone’s help to think this through. either way, the
 patch is much smaller now with the merge of [61007]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61501#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform