Unraveling the Mystery of $_REQUEST: When GET, POST, and COOKIE Collide

$_REQUEST merges GET, POST and COOKIE data, but there are security and predictability risks; when the key conflicts, its override order is determined by variables_order or request_order in php.ini, default is EGPCS, that is, POST override GET and GET override COOKIE; for example, when there are "user" parameters in GET, POST and COOKIE POST value wins; the use of $_REQUEST may lead to security vulnerabilities, unpredictable behavior and difficulty in testing; the best practice is to avoid using $_REQUEST, but should explicitly use $_GET, $_POST or $_COOKIE; it is only used in general filtering, security frameworks or prototype development that are independent of input source; in short, because its behavior depends on configuration and is prone to abuse, specific hyperglobal variables should be preferred to ensure clear and secure code.

When working with PHP, you've likely come across $_GET , $_POST , and $_COOKIE —superglobals that store data from different sources. But there's another one that often raises eyesbrows: $_REQUEST . It's a convenient shortcut, but it can also introduce subtle bugs if you don't understand how it works. Let's break down what $_REQUEST really is, how it behaves when GET, POST, and COOKIE data colleague, and why you should think twice before using it.

What Is $_REQUEST ?

$_REQUEST is a PHP superglobal that, by default, contains the contents of $_GET , $_POST , and $_COOKIE . It's a merged array allowing you to access request data without knowing the method or source upfront.

For example:

 // If you send a GET request: ?name=John
echo $_REQUEST['name']; // Outputs: John

// Or submit a form via POST with name=Jane
echo $_REQUEST['name']; // Outputs: Jane

// Or if a cookie named 'name' exists
echo $_REQUEST['name']; // Outputs the cookie value

This seems handy—no need to check which method was used. But convenience comes at a cost.

How Does $_REQUEST Handle Conflicts?

When the same key exists in more than one of $_GET , $_POST , or $_COOKIE , PHP doesn't merge them—it overwrites them based on a predefined order. This order is controlled by the variables_order or request_order directives in php.ini .

By default, most PHP installations use:

 variables_order = "EGPCS"

Which stands for:

• E → Environment variables
• G → GET
• P → POST
• C → Cookies
• S → Server variables

So when $_REQUEST is popular, values are merged in that order, with later entries overwriting earlier ones.

But here's the catch: $_REQUEST only includes G, P, and C by default, and the priority order is actually determined by the sequence in request_order . If not set, it follows variables_order , and typically, POST takes precedence over GET, which takes precedence over COOKIE .

For example:

 // Request: ?user=admin
// POST data: user=hacker
// Cookie: user=guest

echo $_REQUEST['user']; // Outputs: hacker (POST wins)

This means an attacker could potentially override URL parameters (GET) by including the same parameter in POST—even if your logic assumes the value comes from the query string.

Security and Predictability Risks

Using $_REQUEST can lead to:

• Security vulnerabilities : If you're checking a token in GET but allow it to be overridden via POST or cookies, you might weaken CSRF protections.
• Unpredictable behavior : The same script might behave differently based on how data is sent, making bugs hard to trace.
• Testing complexity : Mocking requests become harder when multiple input sources affect the same variable.

For instance, imagine this code:

 if ($_REQUEST['action'] === 'delete') {
    deleteAccount();
}

An attacker could:

• Send a POST request with action=delete , even if the link was meant to be GET-only.
• Set a malicious cookie that triggers the action unexpectedly.

Best Practices: When (and When Not) to Use $_REQUEST

In most cases, avoid $_REQUEST . Instead:

• Use $_GET when expecting URL parameters.
• Use $_POST for form submissions.
• Use $_COOKIE only when explicitly dealing with cookies.

This makes your code more secure and easier to audit.

However, $_REQUEST might be acceptable in limited scenarios:

• Generic input filters where source doesn't matter (eg, logging all input).
• Frameworks or routers that abstract input handling safely.
• Quick prototypes (but remove it before production).

Even then, explicitly checking each source gives you more control.

Bottom Line

$_REQUEST is like a magic box that combines inputs—but the box has rules you can't always see. When GET, POST, and COOKIE colleague, the winner depends on PHP's internal configuration, not your intent. That unpredictability is dangerous.

Stick to the specific superglobals. Know your data source. Write clearer, safer code.

Basically: just because you can use $_REQUEST , doesn't mean you should .

The above is the detailed content of Unraveling the Mystery of $_REQUEST: When GET, POST, and COOKIE Collide. For more information, please follow other related articles on the PHP Chinese website!