In a web application there could be two approaches to mitigate XSS attacks:

  • all the input data could be filtered (removing all 'bad' data), or
  • the input could be parsed, tokenized and output with only the allowed tags etc

Which method should be preferred from security standpoint?

With either method, what are the gotchas?

5 Answers 5


For input validation, I recommend a whitelist approach combined with pass-or-reject. So define what is valid, and accept only valid input, reject everything else.

If you build a rich text editor that sends html to your server, you can use JavaScript to sanitize the input, so that pasting html from Word could end up working. Yet your server won't accept any unsanitized input.

Trying to clean up is subject to being faulty, as that is usually much more complex then just figuring out if input is valid or not.

Whitelisting is essential to good security. You can always to decide to accept more input, while keeping in control. In a blacklist approach, you'll always have to catch up to the latest hack.

For output, see other answers.

  • 2
    A whitelist approach is definitely the harder of the two from a development standpoint, but I would say it's the way to go for sure. Accept the bare minimum input to start and open it up slowly. Nov 11, 2010 at 22:01
  • 1
    When using white listing you have to update the list when you change the application. With black listing you update the list every day a new exploit is published: everyday. Jul 28, 2011 at 16:25

I agree with @Jorn's answer about the validation.

However, you're still forgetting a very important step here, and that is output encoding.
E.g. HTML encoding (or Attribute encoding, or Javascript encoding, etc) before outputting anything... In fact, this is arguably even more important than the input validation (arguably, not absolutely, and definitely not in all situations...)
In any event it shouldn't be either/or, its definitely both strict input validation + output encoding.

Now, if you are referring to including "safe" HTML tags in the output (then its not very clear in your question), then you should still encode every thing, and then decode the specific tags you're looking for without any of the tag's attributes.

P.s. If you're referring to a .NET app, MS's AntiXSS (in WPL) provides a .GetSafeHTMLXXX set of methods.

  • 2
    +1 for output encoding. Most think that it's enought to validate the input, but neglect to validate the output as well. Nov 12, 2010 at 7:21
  • what's the proper way to do this with jstl tags?
    – Casey
    Dec 8, 2010 at 2:54
  • @Casey, whats jstl?
    – AviD
    Dec 8, 2010 at 8:01

your question "User input data, is filtering enough or should it be parsed?" is more general than the XSS case. I guess, you wanted to be specific for XSS but usually user input can cause many additional exploits like SQL Injection, Path Traversal, XSS... As your question gets more specific on XSS, I would refer to what is already said and go for input filtering and output encoding (always server side!!) with some known countermeasures like the provided by OWASP.

Still, I would like to point you out that the best way to solve SQL Injection that can be caused by the unchecked input is in parametrized queries (SQL Injection Prevention Cheat Sheet) then if you consider path traversal vulnerabilities, my approach would be some whitelisting approach.


The question is too broad. The best answer is: it depends. It depends upon the format of the user data, and what security policy you're are enforcing.

  • For instance, if you are including user data in a SQL query, the best answer is to use prepared statements.

  • For instance, if you are including user data -- say, their full name -- in a HTML page, the best answer may be to use output encoding.

  • For instance, if you are building a webmail service that allows people to send HTML email, and you want to display an HTML email to the user but only if the email doesn't contain any active content, then the best answer is going to involve parsing and filtering the parsed content.

The best answer depends upon the domain. To get a more useful answer, you're going to need to provide more specifics about the concrete problem you're trying to solve.


I would highly recommend not to reinvent the wheel. Sure, every web-developer must know security basics, but if you have possibility to use robust solution - use it. There are high chances that during implementation of your own filter you'll miss something. Proper input validation is not only about removing bad characters - this is complex topic. Anyway, if you have no other option, then look how other WAF's works. One well-known and robust for PHP applications is http://php-ids.org/. And as for attack vectors, just to remind how "fuzzy" they are - http://heideri.ch/jso/.

You must log in to answer this question.

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