HTTPリクエストとは？仕組み・構成要素・主要メソッドと実務で押さえるセキュリティ対策を完全解説
エバープレイ編集部HTTPリクエストとは何か — 概要
HTTP（Hypertext Transfer Protocol）のリクエストは、クライアント（通常はブラウザやAPIクライアント）がサーバに対して行う「要求」のことです。HTTPはクライアント・サーバモデルに基づくアプリケーション層プロトコルで、リクエストはリソースの取得、作成、更新、削除、あるいはサーバに対する問い合わせなど、多様な操作を表現します。リクエストはテキストまたはバイナリ形式（HTTP/2以降はバイナリフレーム）で送信され、サーバはそれに応じてHTTPレスポンスを返します。
HTTPリクエストの構成要素
一般的に、HTTPリクエストは以下の主要要素で構成されます。
- リクエストライン（メソッド、リクエストターゲット、HTTPバージョン）
- ヘッダーフィールド群（メタデータ：Host、User-Agent、Acceptなど）
- 空行（ヘッダーとボディの区切り）
- メッセージボディ（必要に応じて、フォームデータやJSONなど）
リクエストラインの形式（HTTP/1.1の例）
HTTP/1.1では、リクエストラインは次の形式です：METHOD SP Request-URI SP HTTP-Version CRLF。例えば：
GET /index.html HTTP/1.1 Host: example.com User-Agent: curl/7.86.0 Accept: text/html
POSTの場合、メッセージボディとContent-Length（またはTransfer-Encoding: chunked）が含まれます。
主要なHTTPメソッドとその意味
- GET：リソースの取得。副作用を持たない（safe）と想定される。ただし実装次第で副作用が起こり得る。
- HEAD：GETと同様だがメッセージボディは返さない。ヘッダーのみ取得する。
- POST：リソースの作成や処理のトリガー。一般に非冪等（non-idempotent）。
- PUT：対象リソースを置換または作成する。冪等（idempotent）。
- DELETE：リソースの削除。冪等であるべき。
- PATCH：部分的更新。必ずしも冪等ではない。
- OPTIONS：サーバがサポートするメソッドやCORSのプリフライトで使用。
- CONNECT：トンネルの確立（プロキシ経由でTLS接続を確立するなど）。
- TRACE：ループバック診断用（セキュリティ上の理由で無効化されることが多い）。
ヘッダーの役割 — 重要なヘッダー
ヘッダーはリクエストに関する多くのメタ情報を運びます。代表的なもの：
- Host：仮想ホストを識別。HTTP/1.1では必須。
- User-Agent：クライアントソフトウェアの識別。
- Accept、Accept-Language、Accept-Encoding：コンテンツネゴシエーション（クライアントが受け取れる形式や言語、圧縮方式）。
- Content-Type：メッセージボディのMIMEタイプ（例：application/json、multipart/form-data、application/x-www-form-urlencoded）。
- Content-Length：ボディのバイト長。または
Transfer-Encoding: chunkedでチャンク転送。 - Cookie：セッション識別などを行うためのクッキー送信。
- Authorization：ベーシック、Bearerトークン（OAuth）等の認証情報。
- Connection：接続の管理（例：keep-alive、close）。
メッセージボディの形式
リクエストボディには様々な形式があります。よく使われるもの：
- application/x-www-form-urlencoded：HTMLフォームの標準的な送信形式。
- multipart/form-data：ファイルを含むフォーム送信。
- application/json：APIでよく使われるJSONデータ。
- application/octet-stream：バイナリデータ。
HTTPバージョンごとの違い（1.0/1.1/2/3）
- HTTP/1.0：接続ごとに1リクエストが基本。Hostヘッダーがないため仮想ホスティングに不向き。
- HTTP/1.1：持続的接続（keep-alive）、パイプライン（限定的）、Hostヘッダー必須などを導入。
- HTTP/2：バイナリフレーミング、ストリームの多重化、ヘッダー圧縮（HPACK）でレイテンシ削減。
- HTTP/3：トランスポートにTCPではなくQUIC（UDPベース）を利用。接続遅延の低減やヘッドオブラインブロッキングの改善。ヘッダー圧縮はQPACK。
転送の詳細：チャンク転送・Content-Length
サーバへボディを送る場合、事前に長さが分かればContent-Lengthを指定します。長さが不明な場合はTransfer-Encoding: chunkedを使い、データをチャンクに分けて送ります（主にHTTP/1.1で使用）。HTTP/2/3ではフレームベースのためチャンク転送の概念はプロトコルレベルで異なります。
セキュリティ上の考慮点
- HTTPS（HTTP over TLS）を利用して通信の機密性と完全性を確保することが必須です。TLSハンドシェイクではSNIやALPNによりホスト名やアプリケーションプロトコル（http/1.1、h2、h3）を交渉します。
- 認証と認可：Authorizationヘッダー（Basic、Bearer等）やCookieを安全に管理する必要があります。トークンの取り扱い、保存場所（localStorageの問題点など）に注意。
- CORS（クロスオリジンリソース共有）：ブラウザ環境で別オリジンにアクセスする際の制約。複雑なリクエスト（カスタムヘッダーやContent-Typeが標準外）の場合、プリフライト（OPTIONS）リクエストが発生します。
- CSRF（クロスサイトリクエストフォージェリ）：特にCookieベースの認証では、リクエストの正当性検証（CSRFトークン、SameSite属性など）が必要です。
- インジェクション攻撃（SQL/OS/コマンド注入など）：入力検証とパラメタ化されたクエリの使用が重要です。
- レート制限とリクエストサイズ制限：DoSや大量リクエスト対策としてサーバ側で制限・ブロッキングが推奨されます。
CORSとプリフライト（実務での注意点）
ブラウザのセキュリティモデルにより、あるオリジンから別オリジンへの条件付きリクエストは制限されます。プリフライトはOPTIONSメソッドで、サーバが実際のリクエストを受け付けるか確認します。サーバはAccess-Control-Allow-OriginやAccess-Control-Allow-Methods、Access-Control-Allow-Headers等を返す必要があります。
実例：GETとPOSTの生リクエスト（HTTP/1.1）
GETの例：
GET /api/users/123 HTTP/1.1 Host: api.example.com Accept: application/json User-Agent: ExampleClient/1.0
POSTの例（JSON）：
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 48
Authorization: Bearer eyJhbGci...
{
"name": "山田太郎",
"email": "taro@example.com"
}
プロキシ、ロードバランサ、CDNとの関係
HTTPリクエストはプロキシやロードバランサ、CDNを経由することが一般的です。これらはHost/Forwarded/X-Forwarded-Forヘッダーを使って元のクライアント情報や接続経路を伝搬します。これによりログやアクセス制御、地理的ルーティング、キャッシュ制御が可能になりますが、ヘッダーの信頼性については注意が必要です（特に公開プロキシ環境）。
レスポンスとの関係 — リクエスト設計の重要性
リクエストはサーバの振る舞いを決定します。適切なメソッド、ヘッダー、ボディを設計することで、正しいステータスコードやキャッシュ挙動を得られます。例えばGETはキャッシュされ得るため、同一の副作用を伴う操作をGETに実装しないことが原則です。
デバッグと観察ツール
- ブラウザの開発者ツール（Networkタブ）
- curl、httpieなどのコマンドラインクライアント
- Wireshark、tcpdump（ネットワークレベルのキャプチャ。HTTPSは復号が必要）
- APM/ログ集約ツール（例：Elastic Stack, Datadog）
まとめ（実務的なチェックリスト）
- 適切なHTTPメソッドを選ぶ（安全性・冪等性を考慮）。
- HTTPSを常時利用し、TLS周りの最新のベストプラクティス（ALPN、強い暗号スイート）を採用する。
- Content-TypeやContent-Length、Transfer-Encodingを正しく設定する。
- CORS、CSRF、認証方式の設計を行い、ブラウザとAPIの挙動を理解する。
- レート制限や入力検証を実装し、攻撃耐性を高める。
- HTTP/2/3導入時はヘッダー圧縮や多重化の挙動を理解し、既存のミドルウェア（プロキシ/ロードバランサ）との互換性を確認する。
