I am performing security testing on a Rest API and it is a POST method. I injected a XSS script in a body parameter and the API responded with '400 Bad Request' error, but the response displays the XSS script that I have injected in the request payload.

If the response is '200 OK' and if the response body displays the XSS script, then I would have concluded this as a vulnerability, because the XSS script would have been stored and reacted when the respective page is opened in a web browser (if the web application is also weak in security). However, in this case, the response is '400 Bad Request', so do I need to still consider this as a vulnerability?


2 Answers 2


In your case, you perform a POST request and the response give you back your script, it's called a self-XSS.

That's not very useful and not a serious vulnerability in itself, beaucause the purpose of an XSS attack, is to be executed on other user, other accounts, not only yourself. It can be transformed in a traditionnal XSS vulnerability if your API provide some sort of error management system, that could display the message without any sanitisation.


so do I need to still consider this as a vulnerability?

It depends on the details that you have not shared with us. I often have a hard time with raising XSS tickets against APIs because, by definition, an API is returning data and it's the browser / client / javascript that is choosing to execute the API response as code, in which case I would raise a "data-vs-code confusion" ticket against the web client. But in some cases it is the API's fault.

Example where it's the API's fault

If the API is returning HTML content like this:

HTTP/1.1 400 Bad Request
Content-Type: text/html
You submitted:

Then that's clearly the API's fault because the browser has no way to know that <script>alert(0)</script> was meant to be text and not code.


Example where it's not the API's fault

If the API is clearly returning data, for example:

HTTP/1.1 400 Bad Request
Content-Type: application/json
{"errmsg": "You submitted: \"<script>alert(0)</script>\""}

then that's fine because the API is clearly marking this as data, and the javascript client would need to do something very very wrong for that script to get executed.


If I were you, I would keep digging until you can actually trigger a script alert popup, and then decide whether it's the API or the UI that's at fault.

Just to comment on @fmgp's answer: I agree that self-XSS is technically not a vulnerability, it's still sloppy coding practice and should still be pointed out and fixed. For example, that code may get copied into somewhere that is actually dangerous, or an attacker may find a way to trigger that code via a phishing link, commonly by exploiting frameworks that automatically promote GETs with URL params into a POST when there is no GET handler.

You must log in to answer this question.

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