owasp_logo.jpgThe sanitizer does not differentiate between malformed JSON sent by attackers or those originating from developer error.  So it’s helpful in both cases but let me explain.

The time saving point is that as your developing your application depending upon the tools you use to transform JSON it may be more or less easy to make mistakes.  Finding mistakes in your JSON is time consuming and detail oriented work.  JSON is a little easier to read than XML but it’s little comfort with large or complex documents.  The sanitizer saves time since it corrects errant JSON making it well-formed.  I found this behavior useful during development to alert to problems during development and perhaps even post deployment.  Consider the following code fragment,

// Simple sanity checks before we call sanitizer
if( json == null || json.length() < 1 ) {
  throw new MyException(“Missing request”);
// OWASP JSON Sanitizer
String sanitizedJson = JsonSanitizer.sanitize(json);
if( !json.equals(sanitizedJson) ) {
  logger.error(“RAW JSON, detail=”+json); 
  logger.error(“SANITIZED JSON, detail=”+sanitizedJson);
  String msg = “Raw/Sanitized JSON not eq.  Attack or malformed JSON, see log.”;
  throw new MyException(msg);
If there is a difference between raw and well-formed sanitizer JSON then it’s likely, 1) your program has a bug (e.g., encoding, malformed), 2) an attacker is tampering with client JSON to exploit your parser.  Regardless of which case is true, you need to review the JSON to see what went wrong.  Once deployed, you can configure a log4j appender to send alerts so you can investigate offline.  I don’t claim the technique is unique or innovative but it was unexpectedly helpful so I thought I would share the idea.