【実務・中級編】 APIのセキュリティにおけるリクエストボディのハッシュ化(Content-MD5/SHA256) – Web APIアーキテクチャ・データ連携実践ガイド

通信の完全性を守り抜け：リクエストボディのハッシュ化（Content-MD5/SHA256）による改ざん検知の極意

ネットワークエンジニアとして現場に立つと、常に「通信は信用できない」という前提で設計を組む必要があります。どれだけ強固なTLSで経路を暗号化していても、アプリケーション層で「届いたデータが送ったデータそのものであるか」を保証しなければ、APIのセキュリティは砂上の楼閣です。

今回は、REST API設計において、リクエストボディの改ざんを検知するための「ハッシュ値による完全性保証」というトピックを深掘りします。なぜいまさらハッシュ化なのか？それは、APIゲートウェイやプロキシを通過する過程での意図しないデータ破損、あるいは悪意ある中間者攻撃からシステムを守るための「最後の一線」だからです。

—

1. なぜ「ハッシュ値」をヘッダーに含めるのか

HTTPリクエストにおいて、ボディの改ざん検知を担うのが Content-MD5 ヘッダー（あるいはカスタムヘッダーとしての X-Content-SHA256）です。

考え方はシンプルです。送信側でボディのハッシュ値を計算してヘッダーに載せ、受信側（APIサーバー）で同じ計算を行い、その値が一致するかを確認します。

RFC 2616（古の仕様）: Content-MD5 が定義されていますが、現代ではMD5の衝突耐性の低さから、SHA-256などのより堅牢なアルゴリズムを使うのが業界の標準（デファクト）です。
完全性の保証: Content-Length だけでは、データの中身が変わっていないか（途中でビット反転や意図的な置換が起きていないか）は判別できません。ハッシュ値は、データの「指紋」です。

—

2. 通信シーケンスと実務的なフロー

クライアントからサーバーへリクエストが届くまでの流れは以下の通りです。

1. クライアント: 送信ボディデータから SHA-256 ハッシュを生成し、Base64エンコードする。
2. クライアント: X-Content-SHA256 ヘッダーにその値をセットして送信。
3. サーバー: 受け取ったボディを読み込み、同じアルゴリズムでハッシュを計算。
4. サーバー: 送信されてきた X-Content-SHA256 ヘッダーと、自分で計算したハッシュ値を比較。
5. 判定: 不一致の場合は 400 Bad Request または 403 Forbidden を返して即座に処理を中断する。

—

3. 実践：Pythonによる署名リクエストの構築

実際にクライアント側でどのようにヘッダーを構築するか、Pythonの hashlib を使った例を見てみましょう。

import hashlib
import base64
import requests

def send_secure_request(url, payload):
    # 1. ペイロードをバイト列に変換
    body = payload.encode('utf-8')
    
    # 2. SHA-256ハッシュを計算し、Base64でエンコード
    sha256_hash = hashlib.sha256(body).digest()
    hash_header = base64.b64encode(sha256_hash).decode('utf-8')
    
    # 3. ヘッダーに付与してリクエスト送信
    headers = {
        'Content-Type': 'application/json',
        'X-Content-SHA256': hash_header
    }
    
    response = requests.post(url, data=body, headers=headers)
    return response

# 実行例
# サーバー側では、このヘッダーの値と受信ボディを再度ハッシュ化して照合する

—

4. APIサーバー側での検証ロジック

サーバー側（例えばNode.jsやGo）では、ミドルウェア層でこの検証を行うのが最もスマートです。

重要な注意点: ボディ全体をメモリにロードして計算するため、巨大なファイルアップロードを行う場合はストリーム処理が必要です。メモリを枯渇させないよう、検証対象のサイズ制限を設けるのが運用上の鉄則です。

デバッグの勘所：ここがハマりポイントだ

現場でよく見る「ハッシュが合わない」というトラブルの9割はこれです。

改行コードの違い: LF と CRLF が混在していると、ハッシュ値は別物になります。
エンコーディング: JSONシリアライズ時の空白（json.dumps(obj, separators=(',', ':')) のように空白を除くなど）をクライアントとサーバーで統一しておかないと、再現性のないエラーに苦しむことになります。
バイト変換: UTF-8のBom（Byte Order Mark）の有無も確認してください。

—

5. 結論：セキュリティは「多層」で考える

この手法は、署名認証（HMAC）と組み合わせることで真価を発揮します。X-Content-SHA256 で「データの完全性」を担保し、Authorization ヘッダーの署名で「送信元の正当性」を保証する。この2段構えこそが、堅牢なAPI設計の定石です。

もしあなたが今、APIの設計に携わっているなら、まずはこのハッシュチェックを導入してみてください。数行のコード追加で、中間者攻撃に対する耐性が劇的に向上します。「通信を信じない」というネットワークスペシャリストの矜持を、ぜひあなたのコードにも実装してください。

何か不明点や、より深い実装の話（例えば、巨大ファイルに対するChunked Transfer Encoding時のハッシュ検証など）があれば、いつでも質問してください。現場の泥臭い知見を交えて回答します。