I came across this link today that does run XSS on the site it was originally intended for:


I tried this on my site, which has request filtering configured to 404 on img, alert and onerror but this URL was allowed.

I added # to deny rules and I also added it as a deny sequence in the QueryStrings tab, but it was still allowed. Presumably because # is special and anything after it doesn't count as URL or Querystring.

Is it wise to block # if our site(s) don't need it and if so, how can I deny # on IIS7?

2 Answers 2


The string following # is the ‘fragment identifier’ and is normally used to navigate to an anchor element inside an HTML document (but here is used to simulate URL navigation in a single-page-app).

The fragment identifier is used purely by the browser client-side and is not even included in the request to the web server, so you cannot filter it on the server side in IIS or any other server.

(You should not rely on ASP.NET Request Filtering for security. This is only one of the places it fails.)

You could attempt to ‘filter’ it on the client side by including a <script> run before any other script, that sabotages the page and refuses to load any more script if it detects anything it considers ‘bad’ in location.hash, but that's still subject to all the same failure modes of blacklist input sniffing that make Request Validation a waste of everyone's time.

  • I think request validation has it's place as part of strength in depth. Even if it only reduces attacks by script kids and scanners?
    – DomBat
    Jun 16, 2015 at 12:36
  • 1
    It could have some value as an IDS if you were reviewing the attacks it detected, deciding what's a false positive, and using it to block traffic sources generating real attacks. But as an IPS it is only hiding your applications' bugs under the carpet (and sometimes randomly breaking it).
    – bobince
    Jun 16, 2015 at 16:25

What browser is this? This should be automatically blocked by Chromes XSS filter. I'd say the first step would be to set up a proper CSP https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Introducing_Content_Security_Policy

After start mitigating the risks associated with a compromise, like using http-only cookies, CSRF token, and THEN start doing client filters like bobince suggested.

  • Any browser too be honest (my Firefox did warn it was XSS). We have all the usual protections as mentioned but just filtering stuff before it even gets to the app. May as well use the functionality, it's free and easy to setup.:-)
    – DomBat
    Jun 17, 2015 at 8:54

You must log in to answer this question.

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