Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

While going through some references about protection against XSS i found that it is a good practice to encode data (entered by users) before using it to generate a dynamic page. I was not able to find out a detailed explanation of this question is

  1. How does encoding help prevent XSS?
  2. Does it provide full protection against stored XSS?
  3. Are there any other countermeasures that need to be taken into consideration.
share|improve this question
Possible dup of – D.W. Mar 15 '13 at 18:53
But the duplicate question belongs to another website – Shurmajee Mar 19 '13 at 5:46
the meta discussion about this question being a duplicate – Shurmajee Jun 13 '13 at 5:58
up vote 13 down vote accepted

(Copied from my answer on StackOverflow )

HtmlEncode simply does NOT cover all XSS attacks.
Encoding is the correct solution, but not always HTML encoding - you need context-sensitive encoding.

For instance, consider server-generated client-side javascript - the server dynamically outputs htmlencoded values directly into the client-side javascript, htmlencode will not stop injected script from executing.

Next, consider the following pseudocode:

<input value=<%= HtmlEncode(somevar) %> id=textbox>

Now, in case its not immediately obvious, if somevar (sent by the user, of course) is set for example to

a onclick=alert(document.cookie)

the resulting output is

<input value=a onclick=alert(document.cookie) id=textbox>

which would clearly work. Obviously, this can be (almost) any other script... and HtmlEncode would not help much.

There are a few additional vectors to be considered... including the third flavor of XSS, called DOM-based XSS (wherein the malicious script is generated dynamically on the client, e.g. based on # values).

Also don't forget about UTF-7 type attacks - where the attack looks like


Nothing much to encode there...

The solution, of course (in addition to proper and restrictive white-list input validation), is to perform context-sensitive encoding: HtmlEncoding is great IF your output context IS HTML, or maybe you need JavaScriptEncoding, or VBScriptEncoding, or AttributeValueEncoding, or... etc.

If you're using MS ASP.NET, you can use their Anti-XSS Library, which provides all of the necessary context-encoding methods.

Note that all encoding should not be restricted to user input, but also stored values from the database, text files, etc.

Oh, and don't forget to explicitly set the charset, both in the HTTP header AND the META tag, otherwise you'll still have UTF-7 vulnerabilities...

Last point, regarding Stored XSS - since you would be doing the encoding during the page generation, on the data output, it is agnostic as to the source of the data, whether from user input (i.e. Reflected XSS) or Database/files (i.e. Stored/Persistent XSS). (So basically yes.)

Some more information, and a pretty definitive list (no longer updated), check out RSnake's Cheat Sheet:

share|improve this answer
DOM based XSS from the point of defenders is the same as reflected XSS except it's reflected not by server but client code and should be escaped there. – Smit Johnth Mar 18 '13 at 7:33 - I lol'd, who calls a page of 100 kb text a cheat sheet? – Smit Johnth Mar 18 '13 at 7:39

Basically XSS happens when an attacker is successful in executing some kind of unauthorized script on a webpage viewed by a potential victim. So if you HtmlEncode the fields before printing on the webpage, the page will not interpret the data as script. It will interpret the characters as content and the content will be printed on to the page as it is.

eg: say you have something like

<form action="/printname" >
  <input type="textbox" name="name">
  <input type="submit">

and on the server side you have something like

return HttpResponse("hai" + k)

if the user inputs the name as


the page would execute the script instead of printing it. However if suppose the HttpResponse function HTML encodes the output before sending it to the client, < will be replaced by &lt; and > will be replaced by &gt; and the double quotes will be replaced by &quot;.

The result would be the page interpreting the the output as content instead of script.

Hope my answer is clear. And it does help in preventing stored XSS, because the stored value is encoded before printing.

share|improve this answer
Unfortunately, HTML Encoding doesn't provide full protection against XSS.. You're better off by using a well-vetted security library. – Adi Mar 14 '13 at 10:28
right.. it is better to use the rules mentioned in the OWASP page – aRun Mar 14 '13 at 11:00
+100500 to template frameworks and +100500 to OWASP. Only PHP monkeys seem not to use frameworks, see "PHP: Fractal of bad design". – Smit Johnth Mar 18 '13 at 7:35

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.