私はPHPフレームワークを構築しており、その中にURL $_GET、$_POSTおよび、$_FILEスーパーグローバルを解析するリクエストオブジェクトがあります。
安全なWeb習慣を奨励したいので、SQLインジェクションなどからデータを保護しています。
このフレームワークのユーザーがリクエストオブジェクトを介して安全でクリーンなデータにアクセスできるようにするために、unset($_GET, $_POST, $_REQUEST);これらの変数を解析した後に使用する予定です。
これをメソッドのコメントで文書化し、フレームワークの文書でこれが起こっていることを説明します。
私の質問は：これは望ましい行動でしょうか？私が予測していなかった潜在的な落とし穴は何ですか？
私はこれがすでに答えられたことを知っています、しかしここに私の0.02ドルがあります。
入力配列の設定を解除したり、クリアしたりしません。しかし、私がやったことは、それらをオブジェクトに置き換えることです。したがって、生の配列を使用する代わりに、とを実装するオブジェクトに置き換えArrayAccessますIterator。そうすれば、ネイティブ配列を使用するコードの大部分は、オブジェクトで引き続き非常にうまく機能します。
理論的根拠は、少なくともコードパスがテストによって正しく動作していることを確認できるということです。これらのオブジェクトをモックオブジェクトに置き換えて、テスト中に例外をスローし、それらの配列への不適切なアクセスを検出できるようにすることができます（「悪い習慣」であると判断した場合）。そのため、不要な制限を課すことなく本番環境で実行できますが、テスト中にベストプラクティスを検証するためにオンにすることもできます。
エスケープについては@JWに同意しますが、入力をフィルタリングする必要があります。フィルターイン、エスケープアウト。データが（ユーザー入力またはDBから）プログラムに入るときはいつでも、期待値にフィルターをかけます。データが（DBまたはユーザーのいずれかに）送信されるときはいつでも、そのメディアに対して適切にデータをエスケープする必要があります。したがって、送信されたデータを簡単にフィルタリングできるリクエストオブジェクトを使用すると、非常に価値があります。
流暢なインターフェースを使用した例（必要な場合と不要な場合があります）：
$id = $request->get('some_id')->filter('int', array('min' => 1));
また、プラットフォームや構成の違い（たとえば、magic_quotes_gcp有効かどうかなど）を補正するメリットは含まれていません...
とにかく、それは私の意見です...
$_GETまたは$_POST配列へのアクセスを防ぐことのポイントが何であるかわかりません。それらに有害なものは何もありません。SQLインジェクションやクロスサイトスクリプティングを防ぐためのフレームワークを作成している場合は、SQLクエリまたはHTMLドキュメントを作成するときにデータをエスケープする必要があります。
最初にGET/POSTデータをエスケープするのは時期尚早です。データがどのように使用されるかわからないため、データを適切にエスケープまたはエンコードすることはできません。
そうは言っても、コードを介して人々にGET/POSTデータにアクセスしてもらいたいという正当な理由があるかもしれません。その場合でも、設定を解除することはありません。それらに依存するサードパーティのコードを組み込むことになる可能性があります。代わりに、ユーザーにそれらを避けるように勧めてください（一般にグローバル変数を避ける必要があるように）。
おそらく、サニタイズルーチンが予期しない方法でデータを破損する可能性がない場合に、生データを取得するためのメソッド（おそらく非表示または非常に直感に反する;））を公開します。ユーザーを保護することは1つのことですが、最も生の方法でデータを取得する能力からユーザーを完全にロックすると、フラストレーションが生じ、その結果、フレームワークを使用していない人々につながる可能性があります:)
これによりメンテナンスコストが増加することに注意してください...PHPのスーパーグローバルで何かが追加、削除、または変更された場合は、フレームワークを更新する必要があります。
magic_quotesスタイルの考え方のように聞こえます。ただし、少なくともmagic_quotesは実行時に99％リバーシブルでした。「クリーンアップされた」データは損失を伴う可能性があり、これは非常に残念です。