ASP.NET includes a request validation system that halts page processing if any of the following characters are present in the path portion of the URL < > * % & : \ ?. Instead of the normal page, the runtime returns an error page which says

A potentially dangerous Request.Path value was detected from the client

The only information I've been able to find about it being "potentially dangerous" are vague references to XSS. What's the specific problem the runtime is trying to mitigate? If I need to accept URL's in my app that I cannot control and might contain some of the unsafe characters, is it safe to disable the runtime validation?

(There are already numerous articles discussing how to disable validation, but none of them mention the implications of doing so).

  • Do you mean parameters in a URL using an ampersand? If you do mean that, then it can have many vulnerabilities, such as Parameter tampering, XSS if it returns it's contents onto the page, and SQL injection
    – Jack
    Feb 2, 2017 at 12:50
  • @Jack I don't know what I mean. The request validation library returns the message in the question with no explanation. I'm trying to understand what they're worried about and if it's safe to ignore. Feb 2, 2017 at 17:24

1 Answer 1


It's difficult to answer your question about whether it's safe to disable validation without knowing the exact circumstances, but I'd caution against disabling it if you don't do very thorough validation of the path component yourself.

The question mark and ampersand might be dangerous because they are used to pass parameters to an application over an URL. The ampersand is also a problem because html entities can be encoded with it (&auml; produces 'ä'). This isn't really a problem in an URL, but if you get your encoding/decoding slightly wrong and insert a get variable that contains these into your page html, you might allow an attacker to include dangerous html tags such as the script tag, iframes etc. The percent character is a problem because it is used to encode special characters in URLs. And of course the < and > are a problem because these are used for HTML tags.

If your application provides a way to accept the request path (or body content) with these characters from just anyone, someone might think of a way to use them to trick your application into doing something unintended.

For example, if you didn't validate the request path and your application inserted the value of the 'title' variable into your page if it was present, this would be harmless when someone requested an url such as http://www.example.com/profile?user=johndoe&title=John, but someone else might use http://www.example.com/profile?user=johndoe&title=<script>really bad script here<script> (probably encoding the value of the title using percent url encoding) and have his script run in the context of your page.

It would be even worse if you stored the value of the title variable in a database and later showed it to every user who wanted to look at john doe's profile, because that would run the script whenever anyone looked at john doe's profile. The script might then steal these user's cookies or do some other really horrible and evil thing to them. :-) The example is a bit far-fetched, but the basic problem is not.

  • The XSS risk your discussing would only apply if I intend to include content from the URL in the page generated. In that case an ampersand is a bigger risk than any other character b/c it can be used w/ HTML entities which can allow for XSS. What if I don't include any of the URL content on the page? Is the ampersand still a bigger risk? Feb 4, 2017 at 20:50
  • I'd say the percent character was probably more dangerous, because it can be used to encode any byte in an URL. So if you url-decoded the string and then passed it on (say to an OS shell) without validating the contents, mayhem could result. It depends very much on what you do with the string of URL content. If you're passing it to a system where an & will eventually end up having special meaning, you're running a risk. If you don't, there's probably no risk. But it't always good practice to filter user input using a whitelist instead of throwing out characters based on a blacklist. Feb 6, 2017 at 18:14

You must log in to answer this question.

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