title: Burp reporting XSS vulnerability in unescaped HTML in JSON response
body: <p>I have a Rails/Ember one-page app. Burp reports that</p>
  
  <blockquote>
    <p>The value of the 'content_type' JSON parameter is copied into the HTML
    document as plain text between tags. The payload
    da80balert(1)4f31e was submitted in the content_type
    JSON parameter. This input was echoed unmodified in the application's
    response.</p>
  </blockquote>
  
  <p>I can't quite parse this message referring to "is copied into" and "was submitted" in, but basically what is happening is:</p>
  
  <ol>
  <li>A PUT or POST from the client contains <code>...&lt;script&gt;...&lt;/script&gt;...</code> in some field.</li>
  <li>The server handles this request, and sends back the created object in JSON format, which includes the string in question</li>
  <li>The client then displays that string, using the standard Embers/Handlebars <code>{{content_type}}</code>, which HTML-escapes the string and inserts it into the DOM, so the browser displays it on the screen as originally entered (and of course does <strong>NOT</strong> execute it).</li>
  </ol>
  
  <p>So yes, the input was indeed echoed unmodified in the application's response. However, the application's response was not HTML, in which case there would indeed be a problem, but JSON, containing strings which when referred to by Handlebars will always be escaped properly for proper display in the browser.</p>
  
  <p>So my question is, is this in fact a vulnerability? I have taken great care with my Ember app and can prove that no data from JSON objects is ever inserted "raw" into the DOM. Or is this a false positive given rise to by the mere fact the unescaped string may be found in the response if looked for using an unintelligent string comparison, not taking into account the fact that the JSON will be processed/escaped by the client-side framework?</p>
  
  <p>To put it a different way, in a classic webapp spitting out HTML from the server, we know that user input such as the above must be escaped/sanitized properly. Unsanitized data "on the wire" in and of itself represents a vulnerability. However, in a one-page app based on JSON coming back from the server, the escaping/sanitization occurs in the client; the JSON on the "wire" may contain unsanitized data, and this is as expected. Am I missing something here?</p>