Skip to content


Json view html-encodes ampersand, less than, and greater than. #283

bboe opened this Issue · 4 comments

3 participants


When I query the flairlist api (\/api/flairlist/.json), ampersands (&), less than (<), and greater than (>) are html-entity encoded when I feel that they shouldn't be as I am dealing with json, not html pages.

I suspect similar html-entity encoding occurs in other APIs' json-views though I haven't verified that.


Updated to include the general case as this html-encoding happens for comment threads as well. I just found this old ticket, though I don't think the bug should have been closed. Json output should not be html-encoded as it has nothing to do with html. Of course the jquery output should remain as it is, but there is no reason to html-encode json.

The issue can be replicated by adding '<', '>', '&' to any comment or self post, and then viewing the resulting submission's json view.


Don't quote me on this, but I seem to recall that the double-escaping is because of an ancient XSS that we encountered in the wild. A JSON string resembling:

{"some key with HTML in it": "<html><script ..."}

triggered Firefox's mime sniffing to decide that the entire document was HTML (despite the right mime type being sent by the server). An attacker (a real life one, not a theoretical one) wrote a comment containing the exploit text and then had an <iframe> in a page (that they submitted to reddit, natch) resembling:

<iframe src="" />

Since Firefox interpreted it as "valid" HTML page, that then caused arbitrary javascript to be executed in the namespace, which they used to upvote a spammy submission (fortunately not to steal cookies, which would have been way more valuable).

Note that this was years ago, before Firefox was so uppity about their automatic updating. So in-the-wild vulnerable versions may not still exist in great numbers, but it only takes a few of them for a cookie-stealing exploit .

Note also that at this point the double-escaping is part of the API. Lots of people would have to modify their API clients if this were changed. But then, maybe getting rid of the increasing number of imgur_uploader and only_says_lol robots would be a good thing.

I don't think the bug should have been closed

I closed it because it's not a bug.


Thanks for the followup @ketralnis. That is quite an interesting issue and strange that firefox would ignore the explicit mime type. I really hope firefox no longer has this problem, or at least that it's become less a problem than session-jacking due to wireless sniffing (I'd love to see HTTPS everywhere).

I closed it because it's not a bug.

Yes, you are correct: it's not a bug. It's using json in a non-standard way. I guess that would be an annoyance :)

reddit member

I'm going to close this because annoying as it is, it's by-design for security reasons.

@spladug spladug closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.