What's wrong with using $_REQUEST[]?

Question

I\'ve seen a number of posts on here saying not to use the $_REQUEST variable. I usually don\'t, but sometimes it\'s convenient. What\'s wrong with it?

Answer 1

It's very insecure. Also it's awkward since you don't know if you're getting a POST or a GET, or another request. You really should know the difference between them when designing your applications. GET is very insecure as it's passed in the URL and is not suitable for almost anything besides page navigation. POST, while not safe by itself either, provides one level of safetey.

Answer 2

Darren Cook: "Since php 5.3 the default php.ini says only GET and POST data are put into $_REQUEST. See php.net/request_order I just stumbled on this backwards-compatibility break when expecting cookie data to be in $_REQUEST and wondering why it wasn't working!"

Wow... just had some of my scripts stop working because of an upgrade to PHP 5.3. Did the same thing: assume that cookies would be set when using the $_REQUEST variable. With the upgrade exactly that stopped working.

I now call cookie values separately using $_COOKIE["Cookie_name"]...

Answer 3

It's important to understand when to use POST, when to use GET and when to use a cookie. With $_REQUEST, the value you're looking at could have come from any of them. If you expect to get the value from a POST or a GET or from a COOKIE, it's more informative to someone reading your code to use the specific variable instead of $_REQUEST.

Someone else pointed out also that you don't want to all POST's or cookies to be overridden by GETs because there are different cross-site rules for all of them, for instance, if you return ajax data while using $_REQUEST, you are vulnerable to a cross site script attack.

Answer 4

Just make sure to set correct parameter in your php.ini (below is default, as long as not set to GPC, no Cookies are used here)

request_order = "GP"

which means POST overwrites GET and you'll be fine.

The reason for $_REQUEST is simply consolidation of $_GET and $_POST. When sending a form and navigation through lots of links on your page, it is very usefull to have one place which holds the state: $_REQUEST

Answer 5

GET requests should be idempotent and POST requests are generally not. This means that data in $_GET and $_POST should generally be used in different ways.

If your application is using data from $_REQUEST, it will behave the same for both GET and POST requests, which violates the idempotence of GET.

Answer 6

If you know what data you want, you should explicitly ask for it. IMO, GET and POST are two different animals and I can't think of a good reason why you would ever need to mix post data and query strings. If anyone has one, I'd be interested.

It can be convenient to use $_REQUEST when your scripts might respond to either GET or POST in the same manner. I would argue though that this should be an extremely rare case, and in most instances two separate functions to handle two separate concepts, or at the very least checking the method and selecting the correct variables, is preferred. Program flow is usually a lot easier to follow when it's not necessary to cross reference where the variables might be coming from. Be kind to the person who has to maintain your code in 6 months time. It might be you.

In addition to the security problems and WTFs caused by cookies and environment variables in the REQUEST variable (don't get me started on GLOBAL), consider what might happen in the future if PHP started natively supporting other methods such as PUT and DELETE. While it's extremely unlikely that these would be merged into the REQUEST superglobal, it's possible they could be included as on option in the variable_order setting. So you really have no idea whatsoever what REQUEST holds, and what is taking precedence, particularly if your code is deployed on a third-party server.

Is POST safer than GET? Not really. It's better to use GET where practical because it's easier to see in your logs how your application is being exploited when it gets attacked. POST is better for operations that affect domain state because spiders generally don't follow them, and predictive fetching mechanisms won't delete all your content when you log into your CMS. However, the question was not about the merits of GET vs POST, it was about how the receiver should treat the incoming data and why it's bad to merge it, so this is really just a BTW.