A potentially dangerous Request.Path value was detected from the client (*) A potentially dangerous Request.Path value was detected from the client (*) asp.net asp.net

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


If you're using .NET 4.0 you should be able to allow these urls via the web.config

<system.web>    <httpRuntime             requestPathInvalidCharacters="<,>,%,&,:,\,?" /></system.web>

Note, I've just removed the asterisk (*), the original default string is:

<httpRuntime           requestPathInvalidCharacters="<,>,*,%,&,:,\,?" />

See this question for more details.


The * character is not allowed in the path of the URL, but there is no problem using it in the query string:

http://localhost:3286/Search/?q=test*

It's not an encoding issue, the * character has no special meaning in an URL, so it doesn't matter if you URL encode it or not. You would need to encode it using a different scheme, and then decode it.

For example using an arbitrary character as escape character:

query = query.Replace("x", "xxx").Replace("y", "xxy").Replace("*", "xyy");

And decoding:

query = query.Replace("xyy", "*").Replace("xxy", "y").Replace("xxx", "x");


For me, I am working on .net 4.5.2 with web api 2.0,I have the same error, i set it just by adding requestPathInvalidCharacters=""in the requestPathInvalidCharacters you have to set not allowed characters else you have to remove characters that cause this problem.

<system.web>     <httpRuntime targetFramework="4.5.2" requestPathInvalidCharacters="" />     <pages  >      <namespaces>     .... </namespaces>    </pages>   </system.web>

**Note that it is not a good practice, may be a post with this parameter as attribute of an object is better or try to encode the special character.-- After searching on best practice for designing rest api, i found that in search, sort and paginnation, we have to handle the query parameter like this

/companies?search=Digital%26Mckinsey

and this solve the problem when we encode & and remplace it on the url by %26any way, on the server we receive the correct parameter Digital&Mckinsey

this link may help on best practice of designing rest web apihttps://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9