PHPの$_REQUESTはなぜ非推奨とされるのか？セキュリティリスクと代替手段を解説

2026年5月10日

セキュリティ

PHPは、Webアプリケーション開発において世界中で広く利用されているプログラミング言語です。

2026年現在、PHPはバージョンアップを重ね、より厳格で安全なコーディング規約が求められるようになっています。

その中で、古くから存在するスーパーグローバル変数である$_REQUESTは、現代の開発現場において非推奨とされる傾向が強まっています。

多くの開発者が慣習的に利用してきたこの変数が、なぜ今、避けるべき要素として議論されているのでしょうか。

本記事では、$_REQUESTの仕組みから、そこに潜むセキュリティ上のリスク、そして現代のPHP開発で推奨される代替手段について詳しく解説します。

目次 [ close ]

$_REQUESTの定義と基本的な仕組み

まずは、$_REQUESTがどのような役割を持っているのかを正しく理解しましょう。

$_REQUESTは、PHPが提供するスーパーグローバル変数の一つであり、HTTPリクエストを通じて送信されたデータを一括で受け取ることができます。

具体的には、$_GET、$_POST、および$_COOKIEの内容を一つにまとめた連想配列として機能します。

開発者はデータの送信元がGETメソッドなのかPOSTメソッドなのかを意識することなく、一つの変数から値を取り出せる利便性があります。

しかし、この利便性こそが、後に多くのトラブルを引き起こす原因となります。

$_REQUESTに含まれるデータの優先順位は、PHPの設定ファイルであるphp.iniのrequest_orderまたはvariables_orderという項目によって決定されます。

例えば、同じ名前のキーがGETとPOSTの両方で送信された場合、設定次第でどちらかの値が上書きされてしまいます。

このような挙動は、システムが予期せぬ動作をする要因となり得ます。

したがって、$_REQUESTの仕組みを表面的な便利さだけで判断するのは非常に危険です。

なぜ$_REQUESTの使用が推奨されないのか

現代のPHP開発において、$_REQUESTの使用が避けられる理由は多岐にわたります。

主な理由は、データの透過性が失われ、プログラムの堅牢性が低下するためです。

コードを保守・運用する観点からも、多くのデメリットが存在します。

データの出所が不明瞭になる問題

$_REQUESTを使用すると、そのデータがどこから来たのかをコード上で判別することが困難になります。

URLのクエリパラメータ（GET）として送られたのか、フォームのボディ（POST）として送られたのかが曖昧になります。

例えば、注文処理を行うスクリプトにおいて、ユーザーIDを$_REQUEST['user_id']で受け取っているとしましょう。

本来、POSTメソッドで送信されるべきデータが、攻撃者によってGETメソッド（URLの末尾）に付与されて送信されても、プログラムはそれを受け入れてしまいます。

このように、送信元を限定できない設計は、開発者の意図しないパスを通るリクエストを許容することに繋がります。

明示的なコードを書くことは、バグを未然に防ぐための基本原則です。

$_REQUESTはこの原則に反する性質を持っていると言わざるを得ません。

セキュリティ上の脆弱性を招くリスク

セキュリティの観点から見ると、$_REQUESTの使用は深刻なリスクを伴います。

その一つが、クロスサイトリクエストフォージェリ（CSRF）やパラメータの改ざんに対する脆弱性です。

Webアプリケーションは通常、副作用を伴う操作（データの更新や削除）にはPOSTメソッドを使用すべきです。

しかし、$_REQUESTを使用していると、POSTで受け取るべき処理をGETで代用できてしまいます。

これは、攻撃者が罠のリンクを用意し、被害者のブラウザ経由で重要な操作を勝手に実行させる攻撃を容易にします。

また、Cookieの内容が混入する設定になっている場合、ユーザーが意図的に操作できないデータがリクエストパラメータとして扱われるリスクもあります。

CookieにはセッションIDなどの重要な情報が含まれることが多いため、これを他のリクエストデータと同等に扱うのは非常に危険です。

$_REQUESTが引き起こす具体的な問題例

ここでは、$_REQUESTを使用することで発生する具体的な問題について、コード例を交えて見ていきましょう。

以下のコードは、ユーザー設定を更新する処理を想定したものです。

PHP

// 危険な実装例
$userId = $_REQUEST['user_id'];
$email = $_REQUEST['email'];

// データベースの更新処理（例）
updateUserEmail($userId, $email);
echo "ユーザー情報を更新しました。";

このコードには大きな問題が隠されています。

本来、この処理はフォームからのPOSTリクエストによって行われることを想定しています。

しかし、攻撃者が以下のようなURLを作成し、ログイン済みのユーザーに踏ませたとします。

実行結果

https://example.com/update_settings.php?user_id=123&email=attacker@example.com

$_REQUESTを使用している場合、このGETリクエストは正常に処理されてしまいます。

結果として、ユーザーは気づかないうちに自分の登録メールアドレスを攻撃者のものに書き換えられてしまうのです。

もしこれが$_POST['user_id']であれば、GETリクエストによる攻撃は成立しませんでした。

また、デバッグの際にも「どの変数がどこから来たのか」を追跡するのが難しくなります。

複数のエンジニアが関わるプロジェクトにおいて、このような不透明なコードはメンテナンスコストを増大させます。

$_REQUESTに代わる推奨される実装方法

2026年現在のモダンなPHP開発では、$_REQUESTに代わってより明示的で安全な方法が採用されています。

基本となるのは、HTTPメソッドごとに適切なスーパーグローバル変数を使い分けることです。

適切なスーパーグローバル変数の使い分け

HTTPプロトコルの設計思想に基づき、目的に応じて以下の変数を使用してください。

変数名	用途	主なシーン
`$_GET`	データの取得・参照	検索結果のページング、フィルタリング、詳細画面の表示
`$_POST`	データの作成・更新・削除	ユーザー登録、ログイン、設定変更、記事投稿
`$_COOKIE`	クライアント情報の保持	セッション管理、パーソナライズ設定、トラッキング

これらの変数を明示的に使い分けるだけで、アプリケーションの意図は明確になります。

先ほどの危険なコードを、$_POSTを用いて修正してみましょう。

PHP

// 安全な実装例
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    // POSTメソッドからのデータのみを受け取る
    $userId = $_POST['user_id'] ?? null;
    $email = $_POST['email'] ?? null;

    if ($userId && $email) {
        updateUserEmail($userId, $email);
        echo "ユーザー情報を更新しました。";
    }
} else {
    // 不正なアクセスとして処理
    http_response_code(405);
    echo "許可されていないリクエストメソッドです。";
}

このように、$_SERVER['REQUEST_METHOD']を併用してメソッドを確認することで、安全性が飛躍的に向上します。

filter_input関数の活用

生のリクエスト変数（$_POSTや$_GET）を直接操作するのではなく、PHPの組み込み関数であるfilter_inputを使用することも推奨されます。

この関数を使用すると、データの取得と同時にフィルタリングや検証を行うことができます。

PHP

// filter_inputを使用した安全なデータ取得
$userId = filter_input(INPUT_POST, 'user_id', FILTER_VALIDATE_INT);
$email = filter_input(INPUT_POST, 'email', FILTER_VALIDATE_EMAIL);

if ($userId === false || $userId === null) {
    die("不正なユーザーIDです。");
}

if ($email === false || $email === null) {
    die("不正なメールアドレス形式です。");
}

// 検証済みのデータを使用して処理を続行
updateUserEmail($userId, $email);

filter_inputを利用することで、外部からの入力値に対する不備を早期に発見できます。

また、コードの読み手に対しても、「この値は数値であるべき」「この値はメールアドレスであるべき」という意図を明確に伝えることが可能です。

近代的な開発におけるリクエスト管理（PSR-7）

大規模なアプリケーションや現代的なフレームワーク（Laravel、Symfony、CakePHPなど）では、スーパーグローバル変数そのものを直接触る機会は減っています。

代わりに、PSR-7（HTTP Message Interface）といった標準仕様に準拠したオブジェクトが利用されます。

リクエストをオブジェクトとして扱うことで、テスタビリティ（テストのしやすさ）が向上し、依存性の注入が容易になります。

PHP

// フレームワーク等におけるリクエストオブジェクトの例
public function update(Request $request)
{
    // メソッドを限定して値を取得
    $userId = $request->input('user_id');
    $email = $request->post('email'); // POSTのみから取得

    // バリデーション機能との連携
    $validated = $request->validate([
        'user_id' => 'required|integer',
        'email' => 'required|email',
    ]);

    // 更新処理
    User::find($userId)->update(['email' => $email]);
}

このように、フレームワークが提供する抽象化レイヤーを使用することで、開発者は$_REQUESTの仕様に悩まされることなく、安全なコードを記述できます。

もしプロジェクトでフレームワークを採用しているなら、必ずフレームワークが提供するリクエストハンドラを使用してください。