Changes between Initial Version and Version 1 of Ticket #17419, comment 26


Ignore:
Timestamp:
Jan 25, 2016, 6:29:07 PM (9 years ago)
Author:
Florian Apolloner

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #17419, comment 26

    initial v1  
    22> The suggested patch has rather surprising behavior to me, with its custom escaping. Normally an HTML attribute is the *best* place to put JSON-formatted data
    33
    4 I would not necessarily agree on *best*. `<script type="application/json">` is just as valid as a data attribute and requires way less escaping. Strictly speaking, if you are actually putting a lot of small JSON snippets into data attributes, escaping takes up quite a bit of space (And we've all learned by now that compressing the output inside TLS can be dangerous). That aside, your argument is not actually correct; depending on the HTML attribute you are using, different escaping rules apply (think of all the js event attributes [onclick etc…]).
     4I would not necessarily agree on *best*. `<script type="application/json">` is just as valid as a data attribute and requires way less escaping. Strictly speaking, if you are actually putting a lot of small JSON snippets into data attributes, escaping takes up quite a bit of space (And we've all learned by now that compressing the output inside TLS can be dangerous). That aside, your argument is not actually correct; depending on the HTML attribute you are using, different escaping rules apply (think of all the js event attributes [onclick etc…]). So in that sense: "Fully" (for some definition of fully) escaped output is not safe anywhere it ends up.
    55
    66So in the end, we at least need documentation on how to safely use JSON in HTML (though one might argue that docs exist already outside of Django and this is not Django specific) and/or make usages outside of `data-*` attributes also safe (ie the json filter for the most "common" situations).
Back to Top