揭開$ _request的奧秘：獲得，張貼和餅乾發生衝突

$_REQUEST合併GET、POST和COOKIE數據，但存在安全和可預測性風險；當鍵衝突時，其覆蓋順序由php.ini中的variables_order或request_order決定，默認為EGPCS，即POST覆蓋GET，GET覆蓋COOKIE；例如，當GET、POST和COOKIE中均有"user"參數時，POST值勝出；使用$_REQUEST可能導致安全漏洞、行為不可預測及測試困難；最佳實踐是避免使用$_REQUEST，而應明確使用$_GET、$_POST或$_COOKIE；僅在輸入源無關的通用過濾、安全框架或原型開發中有限使用；總之，由於其行為依賴配置且易被濫用，應優先選擇特定超全局變量以確保代碼清晰與安全。

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 eyebrows: $_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 collide, 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 populated, 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 becomes 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 collide, 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 .

以上是揭開$ _request的奧秘：獲得，張貼和餅乾發生衝突的詳細內容。更多資訊請關注PHP中文網其他相關文章！