I ran a vulnerability scan on my application using Burp suite. Some of my input fields can take HTML code (e.g. <script>alert("exploited")</script>) and it will be displayed as text but never executed as HTML or script. To be specific it is stored as a string and is always treated as such.

Please find below screenshot:

Screenshot of JS code displayed as text on webpage.

I believe this cannot be treated as XSS vulnerability, since the script never really gets executed. Is that correct, or am I vulnerable here?

  • 1
    Your question isn't clear to me. So input is displayed, but not executed? Or not "really" (what does that mean)? In that case, it's obviously not a vulnerability. Why would you believe that there would be an XSS vulnerability? Did Burp say so? If so, we need more information, especially how the actual HTML source code looks (is the input encoded, where is it, is it read out via JavaScript and operated on, etc). It's also unclear to me how alert("exploited") is HTML code. I'm voting to close for now as unclear.
    – tim
    Commented Jan 25, 2018 at 20:04

1 Answer 1


When this is the code the attacker tried to inject, then this is the intended behavior of a secure web application. The application apparently escaped the javascript code correctly and demonstrated the ability to output it as text without executing it. Note that <script>alert('you can also "inject" valid JavaScript code into Stackexchange without it getting executed by browsers of any other users')</script>.

A different solution would be to filter the user input to remove any "evil" characters like <, >, ' or ". But such solutions are only the second best, because they might result in unexpected behavior in form of overblocking non-malicious input (What do you mean, my username can't be <'_'>?) or might not catch every "evil" character an attacker might come up with.


You must log in to answer this question.

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