I'm testing an application that only skips < and > symbols. The user input being validated is always inserted between html tags like <b>, <span>, <div>, etc. and never passed to the page as an attribute. Is it enough protection or there is a way to bypass this kind of filter?


<a href="http://www.site.com" style="color:white">


  • 2
    Don't strip characters, encode them. Or better yet, have your web framework encode them automagically. Commented Aug 13, 2013 at 14:54
  • I agree with CodesInChaos... for the cost of development, you might as well output encode as necessary for the context rather than have a weak input sanitisation process as a form of security. What happens in future when the user input ends up as a JavaScript variable or as a field in an <input> tag? Commented Aug 14, 2013 at 15:26
  • Not sure I understand the problem correctly, but what if $UserInput = &lt;script&gt;alert(1);&lt;/script&gt?
    – Luc
    Commented Dec 9, 2013 at 18:59
  • Should that be &lt or should it be < in the title?
    – Anders
    Commented Nov 16, 2018 at 8:15

3 Answers 3


This is not sufficient protection

There are many ways an attacker might be able to sneak in a byte sequence that will be interpreted by someone's browser as markup.

In your case, it might even be possible just to use ampersand encoding to pass < and > chars.

Failing that, double encoding could be used to bypass your filters, or even overlong utf-8 sequences (however this last one is a bit outdated and most software stacks don't fall for it).

Those are just a few examples, but there are many more ways of bypassing simple markup filters like yours. This bit in particular is relevant.

  • I tried all those methods but no one worked. Also I realized that < and > are not filtered only actual html tags.
    – Nucklear
    Commented Aug 13, 2013 at 13:53
  • 1
    @Nucklear if you have thrown everything from that OWASP page at your filter, then you're probably pretty good. Whitelisting is still the preferred approach however. eg msg.matches("[\w\s]*")
    – lynks
    Commented Aug 13, 2013 at 13:59
  • How could ampersand encoding be used? I don't get that. As for double encoding and using different character encodings, they only work if the developer has made some specific mistakes. That may or may not be the case here.
    – Anders
    Commented Nov 16, 2018 at 8:20
  • Imagine I have a comment area. I put <script>alert('hello')</script>. The server convert < to &lt; etc... and save this string in db &lt;script&gt;alert('hello')&lt;/script&gt; then in the comment we will see this string. How can you by pass that ?
    – John
    Commented May 22, 2019 at 8:19

Oh, where to begin...

If there's one tenet of security that proves itself again and again and again it's that blacklists fail.

Play the long game - sure your web-application may resist the limited number of attacks you threw at it today, but the internet is going to be able to try thousands of more things with thousands of more variables (new code, different browsers, different language sets, etc, etc, etc).

"The user input being validated is always" -- says you today. What happens when you move on and another developer inherits that code? Are they going to understand and honor the commitments you made to yourself in your head? If you do input validation and output encoding, you give the next guy a fighting chance.

Go ahead and strip out ""<script>", what happens when someone submits ""<scr<script>ipt>"" ?


Who is providing the HREF within the url you provided here:

    <a href="http://www.site.com" style="color:white">

If the href is being pulled from an input tag. Then this is just yet another case of not enough filtering or escaping of user input. All user input needs to be considered evil.

For instance, if it is the user supplying the URL for that anchor tag in your example case, it is entirely possible that this sXSS will work and load on every mouse over:

URL:  http://www.site.com" onmouseover="javascript:alert(1)"

Alternatively, you could change the onmousover to onload and now you have your javascript executing on every page load. Disabling DOM events from within HTML tags is another method of preventing this type of a sXSS attack.

You must log in to answer this question.

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