揭开$ _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 (e.g., 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中文网其他相关文章！