6

According to the OWASP Application Security Verification Standard:

V11.3 Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8).

According to the RFC for the application/json Media Type:

JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.

Since the first two characters of a JSON text will always be ASCII characters [RFC0020], it is possible to determine whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking at the pattern of nulls in the first four octets.

If your encoding is in fact UTF-8, this implies there is no security benefit to setting the Content-Type header to application/json; charset=utf-8 instead of just application/json.

Is it reasonable to make an exception to the OWASP rule for application/json?

Anders
  • 64,406
  • 24
  • 178
  • 215
oggmonster
  • 285
  • 1
  • 2
  • 5

1 Answers1

5

Your biggest risk would be older versions of Internet Explorer that attempt to auto-detect the encoding as UTF-7 - called Codepage Sniffing.

It appears that Internet Explorer will only do this for webpages, and not for AJAX requests. Therefore JSON requests should be safe. Moreover, JSON requests do not cause rendering of content directly to the page - they would need JavaScript processing in order to manipulate the DOM, so this would only be of concern when you were retrieving data that has supposedly been pre-HTML encoded. Therefore if the JSON data is HTML encoded on the client, the encoding of the page should take precedence and would not cause conversion of +ADw- character sequences to angle brackets, which is where the risk lies with UTF-7.

So I would say specifying charset=utf-8 is only necessary for Content-Type: text/html pages.

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178