Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I was reading a Q&A on enabling + characters in URLs for Sitecore CMS, and the answer states:

ASPNET application does not allow using “+” from the security point of view e.g. preventing SQL or JScript attack via URLs.

Essentially a url such as is allowed in the system, while is not.

I have never heard of + characters being used as any sort of attack vector for SQL injection or XSS, but that doesn't mean that there isn't one.

Is + as an alternative to %20 an attack vector of any sort?

NOTE: I've tagged XSS and sql-injection because they were called out explicitly in the article

share|improve this question
up vote 6 down vote accepted

Just for reference: http://host/path?query

The + symbol is somewhat problematic in URIs, this is because it is interpreted differently by different URI encoder/decoders. It is always interpreted as a space if it occurs in the query part of the URI (everything after the ?), however whether it is interpreted as a space if it occurs in the path part of the URI is down the the decoder used.

Your example uses the path section, and the answer will depend upon precisely what decoder you are using. Most of them will not decode + to space when it occurs in path, but you don't know until you try with your specific decoder. This is exactly the type of nasty sanitisation-bypass that can bite you :P

share|improve this answer

%20 and + are two different, although related forms of encoding a space (0x20):

The latter application/x-www-form-urlencoded is the default encoding for forms. With the GET form method, the for data is simply appended to the form’s action URL in the query part. This is a convention introduced with HTML.

So besides the general encoding convention for URLs, the percent-encoding, web servers or applications, which should be able to process parameterized GET requests, must be able to decode the application/x-www-form-urlencoded as well, but only for the query as per HTML specification.

Other parts of the URL, as in your case the URL’s path, are not subject to the application/x-www-form-urlencoded encoding by default. Some web servers/applications may decode it as well, but it’s not standardized behavior.

But I can’t quite see how allowing a + in URLs might prone a security risk, particularly if it gets decoded to a space. There are techniques of the mentioned “SQL or JScript attack” that work without any + or space at all. So I guess it’s rather a pre-cautious whitelisting or blacklisting of certain characters, including the +.

share|improve this answer
+  is an arithmetic operator in the sql language. 

If your throws an error also when you use those mathematical operators: +, -, / . Then it might be the reason why!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.