Take the 2-minute tour ×

I have recently received a recommendation, from a third party, to encode HTML special characters in all server responses "for security reasons". So:

' --> &#x27;
& --> &#x26;


{ "id": 1, "name": "Miles O&#x27;Brien" }

Question: Is there a security gain in doing this, or is it just a paranoia?

share|improve this question

3 Answers 3

up vote 2 down vote accepted
& --> &#x26;

Are you sure this was the kind of encoding they meant?

There is a reason to encode HTML-special characters being returned inside JSON responses, and that's to avoid XSS causing by unwanted type-sniffing. For example if you had:

{ "name": "<body>Mister <script>...</script>" }

and an attacker included a link to your JSON-returning resource in an HTML context (eg iframe src) then a stupid browser might decide that, due to the giveaway string <body>, your document was not a JSON object but an HTML document. It could then execute the script in your security context, leading to XSS vulns.

The solution to this is to use JSON string literal escaping, for example:

{ "name": "\u003Cbody\u003EMister \u003Cscript\u003E...\u003C/script\u003E" }

Using HTML-escaping in this context, whilst it avoids the problem, has the side-effect of changing the meaning of the strings. "Miles O&#x27;Brien" read by a JSON parser is still Miles O&#x27;Brien with the ampersand-x-twenty-seven in it, so if you're writing that value to the page using the likes of .value, .textContent or jQuery .text() it's going to look weird.

Now if you were assigning that string to .innerHTML or jQuery .html() instead, then yeah, you'd definitely need to HTML-escape it at some point, regardless of the JSON XSS problem. However I'd suggest that in this case, for separation-of-concerns reasons, that point should be at the client end where you're actually injecting the content into HTML markup, rather than the server side generating the JSON. In general it is better to avoid injecting strings into markup anyhow, when safer DOM-style methods are available.

share|improve this answer
Thank you for a comprehensive answer. Yes, I'm sure that this is the type of encoding they want. That's why I'm surprised. And also - this is the data for forms (inputs/textareas) so it is already causing some problems, hence the question. And lastly - data for the json is coming from the DB, and is assumed to be sanitized and validated against all possible attacks, injections and hacks. –  tborychowski Nov 5 '12 at 18:29
I wouldn't necessarily put my faith in input sanitisation to deal with an output-formatting issue, but still, yes, passing HTML-encoded data in a JSON response seems off. You could manually unescape it at the client end to prevent O&#x27;Brien appearing in form fields, but that seems like a silly alternative when using JSON \u encoding would avoid the HTML-in-JSON problem without requiring the extra step. –  bobince Nov 5 '12 at 18:35
Would you be able to post some links/references to read more about "JSON string literal escaping"? –  tborychowski Nov 5 '12 at 19:01

Depending on what you are using the data for, yes there is a security benefit.

If you were taking user input, and sending it back to your server, then using it to interact with your database; I could potentially terminate one of your strings, and inject my own SQL statements. And even without a malicious mindset, you sending around quotation characters could accidentally terminate strings.

share|improve this answer
I understand why it is good to encode user input, but if the data in the DB is already sanitized and validated and the response is just a static record from the DB? –  tborychowski Nov 5 '12 at 17:00
If everything is sanitized properly, then I don't see any security benefit of the encoding –  Petey B Nov 5 '12 at 17:02

There seems to be a tendency to protect novice/stupid/naive developers from creating XSS holes in their sites. Especially when someone else is going to deal with these responses (e.g. open API, some junior developer on your team) he might forget to properly HTML-encode the strings before feeding them to some $('#myelement).html() method. The idea is that escaping these responses on the server will result in double escaping (worst case) for developers who don't understand escaping, whereas "smart" developers will know when to unescape the values before using them. The alternative being that "less smart" developers will create a site filled with XSS security holes.

Personally I'm not a big fan of this tendency, but I certainly see how it will result in a safer internet overall, especially as web development is more and more being practiced as a hobby.... What you choose to do is up to you, but this is the rationale behind the request to html-escape all strings in JSON.

Examples of others doing this:

  • Spotify
  • Open Social (I don't have a link, I'm sure you'll take my word for it)
share|improve this answer

Your Answer


