GETとPOSTは「データの送り方の違い」として説明されることが多いですが、実務ではそれ以上に設計とセキュリティに直結する重要な判断ポイントです。
特に問題になるのは、「POSTの方が安全」「GETは使わない方がいい」といった誤解です。この認識のまま開発すると、普通に事故が起きます。
通信の前提を理解するなら、 DNSの役割とドメイン設定 もあわせて確認すると全体像がつながります。
まず最も重要な前提です。
GETとPOSTの違いは「安全かどうか」ではありません。
どちらもHTTPなら盗聴されますし、HTTPSならどちらも暗号化されます。
つまり安全性は次の1点で決まります。
HTTPSを使っているかどうか
この前提を外したまま「POSTだから安心」と思っていると、ログイン情報や個人情報が普通に漏れます。
GETの最大の特徴は「URLにすべて出ること」です。これがそのままリスクになります。
例えば以下のようなリクエストです。
/login?email=test@example.com&password=123456
この設計は一見動きますが、実務では完全にアウトです。
理由はシンプルで、情報があらゆる場所に残るからです。
つまり、GETに機密情報を載せると「漏れる前提の設計」になります。
さらに問題なのが、GETはリンクを踏むだけで実行される点です。
以下のようなコードがあると、ユーザーは気づかないうちに処理を実行させられます。
<img src="https://example.com/delete?id=123">
これはCSRFの典型パターンで、「見ただけで削除される」状態になります。
POSTは「URLに出ない」ため安全そうに見えますが、それは錯覚です。
実際には次のような問題があります。
開発者ツールを開けば、POSTの内容は普通に確認できます。HTTP通信であれば盗聴も可能です。
つまり、POSTは「隠れているだけ」であり、セキュリティとは無関係です。
POSTでも外部サイトから自動送信すれば、不正リクエストは成立します。
つまり、POSTだから安全という考えは完全に誤りです。
POSTは再送信が可能なため、決済や登録で「二重処理」が発生します。
実際の現場では「決済が2回通った」「注文が重複した」といった事故は珍しくありません。
かなり典型的な失敗例です。
本来POSTで実装すべき削除処理を、GETで作ってしまったケースです。
/admin/user/delete?id=125
この設計の何が危険かというと、「URLにアクセスしただけで削除される」点です。
その結果、以下のような事故が起きます。
つまり、GETで状態変更をすると「誰でもいつでも実行できる操作」になります。
実務ではシンプルに以下で判断します。
これだけです。
さらにセキュリティ観点では次のルールが重要です。
このルールを守るだけで、ほとんどの事故は防げます。
GETとPOSTの違いは単なる仕様ではなく、設計ミスがそのまま事故につながる領域です。
特に重要なのは次の2点です。
GETは「見られてもいいもの」
POSTは「変更するもの」
そしてどちらにも共通して必要なのが、HTTPSとCSRF対策です。
ここを外さなければ、Webアプリの基本的なセキュリティは大きく崩れません。