HTTP・HTTPS | Security Atlas

画面の表示はリクエストとレスポンスの往復から始まる

HTTPは、ブラウザなどのクライアントと、ページやデータを提供するサーバーとの通信の約束です。クライアントが送る依頼をリクエスト、サーバーが返す結果をレスポンスと呼びます。

たとえば利用者が商品ページを開くと、ブラウザはそのページの取得をサーバーへ依頼します。サーバーはページのHTMLを返し、ブラウザが読み取って表示します。画像や追加データが必要なら、それぞれについても通信します。

リクエストは操作・対象・付加情報・本文で読む

メソッドは操作の種類です。GETは情報の取得、POSTはデータの送信や処理の依頼などに使います。パスは /products/42 のような対象の指定です。ヘッダーは通信に付ける名前と値の組で、本文の形式や認証情報などを伝えます。本文には投稿内容などを入れます。

次の例はHTTP/1.1の表記です。Hostは宛先のホスト名、Acceptは受け取りたい形式です。GETに認証機能が備わるわけではなく、非公開の商品ならサーバー側で閲覧権限を調べる必要があります。

説明用の通信例・設定例・擬似コード

GET /products/42 HTTP/1.1
Host: shop.example
Accept: application/json

参照：出典 s1

ステータスと本文を分けて確認する

レスポンスのステータスコードは処理の結果を表します。200は成功、401は有効な認証情報が必要な状態、403は処理の拒否、404は対象が見つからない状態などです。実際にどのコードを返すかはサービスの設計にもよります。

Content-Typeは本文の形式を示すヘッダーです。application/jsonなら、名前と値を組にするJSON形式のデータを示します。画面がエラーでも、サーバーが200を返す実装はあり得るので、コードと本文の両方を読みます。

説明用の通信例・設定例・擬似コード

HTTP/1.1 200 OK
Content-Type: application/json

{"id":42,"name":"Notebook"}

参照：出典 s1

HTTPSは通信経路での盗み見や改ざんを防ぐ

HTTPSはHTTPをTLSという通信保護の仕組みと組み合わせたものです。ブラウザは接続先の証明書などを確認し、通信を暗号化してから、ページの要求やログイン情報を送ります。経路上で通信を観察する第三者が、パスワードや本文をそのまま読める状態を防ぎます。

保護はTLSの通信相手までです。たとえば配信サービスがTLSを終端して自社のサーバーへ転送する場合、配信サービスからサーバーまでの保護は別途設計します。受信したサーバー自体は、処理のために本文を読めます。

参照：出典 s2

HTTPSのサイトでも入力処理と権限確認は必要

説明用の例として、サーバーが /invoices/7 の請求書をログイン済みの全員に返す実装を考えます。攻撃者が自分のアカウントでそのURLを要求すると、サーバーは他人の請求書を攻撃者へ返してしまいます。通信が暗号化されていても、サーバーが所有者を調べなければ、他人の請求書を返す処理を止められません。

また、HTTPSの偽サイトへ利用者自身がパスワードを送れば、そのサイトの運営者はパスワードを受け取れます。HTTPSの表示だけで運営者の誠実さやアプリの安全性は判断できません。

参照：出典 s1 / 出典 s2

開発者ツールで一往復を確認する

自分が管理するサイトでブラウザの開発者ツールを開き、Network欄から通信を一つ選びます。宛先URL、メソッド、ステータス、送受信ヘッダー、本文の順で見ると、画面と通信の対応を追えます。

確認問題：POSTで送ればパスワードは暗号化されるでしょうか。答えは、メソッドだけでは暗号化されません。通信経路の保護にはHTTPSが必要です。通信記録には認証情報が含まれることがあるため、共有するときは実際の値を除きます。

参照：出典 s1 / 出典 s2

出典・確認範囲

[s1] Overview of HTTPMDN / 確認日 2026-11-03
[s2] The Transport Layer Security (TLS) Protocol Version 1.3IETF / RFC 8446 / 確認日 2026-11-03

未確認事項・限界

通信例・設定例・被害の例は、仕組みを理解するための仮定です。特定の製品で発生した事件を示すものではありません。ブラウザやサービス固有の設定は、利用する環境の公式資料でも確認してください。