情報処理安全確保支援士 2025年 春期 午前2 問20

フォーム送信データの格納【午前2解説】

正解の理由

解法ステップ

1. HTTPリクエストの構成（リクエスト行、ヘッダー、メッセージボディ）を確認する。
2. GETとPOSTの一般的な振る舞いを思い出す：GETはクエリ文字列を使う、POSTはボディを使う。
3. 選択肢と照合する：GET → リクエスト行、POST → メッセージボディ となる組合せを選ぶ。
4. セキュリティやヘッダーの役割を踏まえ、誤答を排除する（ヘッダーはフォームデータの本体を入れる場所ではない）。

選択肢別の誤答解説

• ア：GETがリクエスト行に格納される点は合っているが、POSTをヘッダーに格納するとしているため誤り。ヘッダーはメタ情報（Content-Typeなど）を持つ場所で、フォームデータの本体は入らない。
• ウ：両方ともヘッダーに入るとするのは誤り。GETのデータはURI（リクエスト行）に、POSTのデータはメッセージボディに入る。ヘッダーにフォームの本体が格納されることは通常ない。
• エ：GETをヘッダーに入れるとするのは誤り（GETはクエリ文字列としてリクエスト行に含まれる）。POSTをメッセージボディに入れる点は正しいが、組合せとして間違い。
• 正答である イ：GET＝リクエスト行（クエリ文字列）、POST＝メッセージボディ、という正しい組合せ。

よくある誤解

1. 「POSTは安全」は誤り：POSTはURLにデータを含めないため露出リスクは下がるが、通信内容の機密性はTLS（HTTPS）で確保する必要がある。
2. 「ヘッダーにフォームデータを入れることがある」は誤り：ヘッダーはデータ形式や長さなどのメタ情報を表す場所で、フォーム本体はメッセージボディに入る（例外的な実装を除く）。
3. 「GETにデータ量の制限はない」は不正確：仕様上は厳密な長さ制限はないが、ブラウザやサーバ、プロキシでURL長の制限があり大きなデータ送信には不向き。

補足コラム

• フォーム送信の標準的なContent-Type：
  • application/x-www-form-urlencoded：デフォルトのフォーム送信（名前=値のエンコード）
  • multipart/form-data：ファイルアップロードなどバイナリを含む場合
• サーバ側の受け取り方の目安：
  • GET → サーバはリクエスト行からクエリ文字列を解析してパラメータを得る。
  • POST → ヘッダーのContent-Typeを見てボディの解析方法を決め、メッセージボディからパラメータを抽出する。
• 実用上の選び方：
  • 参照可能で副作用のない検索やページ遷移 → GET
  • データ作成・更新や大きなデータ・ファイル送信 → POST

# GETの例（クエリ文字列がリクエスト行に含まれる）
GET /search?q=情報&lang=ja HTTP/1.1
Host: example.com
User-Agent: ExampleAgent/1.0

# POSTの例（フォームデータがメッセージボディに含まれる）
POST /submit HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

name=%E4%BE%8B&comment=%E3%81%93%E3%82%93%E3%81%AB%E3%81%A1%E3%81%AF

FAQ