I am new to security and trying to improve. Sometimes when I try to find XSS vulnerabilities on a website my payload just get displayed on the screen but nothing happens. The whole payload just gets displayed as a string. What does this mean?

I saw that just below that the form often there is a hidden input field with some token. Does the payload just get displayed because it's first encrypted to that token and not sent? Or am I completely wrong?

enter image description here

This is an example, why are the italic tags just considered as a string and not as real HTML tags?

  • 2
    I'd guess it means that there is no XSS vulnerability.
    – floworbit
    Commented Nov 22, 2018 at 12:26
  • Why do you think there is an XSS vulnerability? How do you check it? Can you share a screenshot? Are you viewing the source of the page? Do you use developer tools or something like Burp Suite? Are brackets < encoded as &lt;?
    – Sjoerd
    Commented Nov 22, 2018 at 13:44
  • I am relatively new to security and I was just practicing XSS on some websites that are listed on hackerone. I try some basic payloads and I check the source code to see what happens and where the input "goes". I am not using tools. The brackets are encoded, yes. Commented Nov 22, 2018 at 14:07
  • 1
    I think that you need to read about the standard XSS defense techniques including "escaping".
    – schroeder
    Commented Nov 23, 2018 at 20:05

3 Answers 3


Without a screenshot of your results it’s impossible to say for certain, but it sounds with 99.999% confidence that the target is not vulnerable to XSS. Congrats to the developer!

If you’re looking for a way to practice executing XSS, you might consider building your own (private) vulnerable application. An input field with unescaped inputs should do the trick nicely. There are also a number of sites and games that are intentionally vulnerable as a learning tool, to let people practice executing XSS.

Finally, regarding this:

Does the payload just get displayed because it's first encrypted to that token and not sent?

I think you’re overthinking this actually. I don’t think encryption plays a factor here - rather, the critical piece is whether or not your input is escaped. (Definitely look up escaping if you’re not familiar with it.) Unescaped input is always a liability, whether it’s received as plaintext that has never been encrypted, or as decrypted ciphertext. The application sees it the same way.

Further, no one out here in Internet Land is able to answer this question definitively, since we don’t know the application or its architecture. Good question though, and I think you’re on the right track - you’re correct that something is being transformed away from JavaScript so that it can’t be executed. The only difference is that the transformation that makes input safe and unexecutable is escaping rather than encryption*.

*Although it’s important to note that yes, even representing unescaped JavaScript, ciphertext cannot be executed as it only represents JavaScript and is not itself JavaScript without the necessary decryption key(s).


The Inputs are escaped.

In php there is a function for this:

htmlentities($str, ENT_QUOTES);

source: http://php.net/manual/de/function.htmlentities.php


Your input is being escaped. If you select your payload in the developer tools, right-click, and choose "Edit as HTML", you should see that your payload is rendered as something along the lines of &lt;i&gt;hello&lt;/i&gt;.

You must log in to answer this question.

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