I was testing an application recently and i came across with a Reflected XSS vulnerability via HTTP POST Request with JSON body. Although this condition can't be exploitable from his own, due respond's corresponding MIME type application/json preventing the reflected payload to trigger an XSS. However, this endpoint for some reason responds with a wrong MIME type of "text/html", thus if you supply the request with "alert(1)" it triggers a reflected XSS.


HTTP Request

POST /some/app/endpoint HTTP/2
Host: api.vulnapp.com


HTTP Response

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 117

[{"id":"xxxxxx <script>alert(1)</script>","wasSuccessful":true,"data":{"result":{}}}]

Can be this vulnerability exploitable?

2 Answers 2


It depends on how strongly the content-type requirement is enforced. There are three possibilities here:

  • Most of the time, the server only cares that the content can be parsed as JSON and ignores the Content-type header entirely. This is exploitable as it is trivial to send valid JSON payloads using text/plain but also possible to send them using application/x-www-form-urlencoded, the default format for HTML forms. Both of those can be used for reflected XSS attacks, via linking the victim to a page with an auto-submitting HTML form.
  • Sometimes the server checks, but poorly. An example might be attempting to verify that the string "json" exists in the content type header value, without actually correctly parsing the value. This might or might not be exploitable, depending on how bad the issue is. A malicious client might send something like Content-type: text/plain; charset=utf-8; fake=application/json and thus bamboozle the server, but it's possible (as in, I'm not sure and this might be browser-dependent) that a browser can't be coerced into sending such a content type for navigation requests, and that's what matters.
  • Sometimes the server checks correctly. In those cases, this is not directly exploitable, because there is no way to send an actual application/json request as a navigation request, and reflected XSS only works with navigation requests (it doesn't work with scripted requests, such as fetch or XMLHttpRequest or wrappers around those). However, such situations might still be at some risk of a DOM-based XSS, if an attacker can influence the request content and the client code will inject the (supposedly-safe) HTML directly into a document.

With all that said, it is absolutely a security bug, even if not yet a vulnerability. Reflecting request content into the response body without any modification (usually output encoding) is always risky. Doing so into an HTML response body is deeply risky and approximately never correct behavior (either the response type shouldn't be text/html, or the content should be HTML-encoded). Even in the best case, this is extremely fragile, as it's depending on something that probably isn't seen by developers as a security check - the content-type requirement - to perform a security purposes. That's incredibly fragile; I've seen first-hand situations where somebody switches a response parsing library from one that validates the content type to one that doesn't, or removes a narrow content-type filter because they want to allow valid requests to use some other type too and don't see that filtering narrowly is important. In other words, this is at minimum a Low-severity defense-in-depth bug, and quite possibly worse than that (depending on your exact bug bar).


Yes, if there is no CSRF protection in place and the content-type is text/html the vulnerability is exploitable.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .