HTTPメソッド改ざん（HTTP Verb Tampering）とは？認証バイパス脆弱性の仕組みと対策をわかりやすく解説

認証があるはずなのに管理画面に入れてしまった。ログイン不要でデータを更新できてしまった。そんな「穴」が、HTTP通信の根幹にあるメソッドのわずかな取り扱いミスから生まれることがあります。

HTTPメソッド改ざん（HTTP Verb Tampering）は、GETやPOSTといった一般的なHTTPメソッド以外を意図的に送りつけ、サーバー側の認証・認可ロジックをすり抜ける攻撃手法です。ツールも知識も最低限あれば試みられるため、Webアプリケーションを運用するすべての現場で正しく理解しておく必要があります。

この記事では、HTTPメソッド改ざんの仕組みから具体的な攻撃シナリオ、そして開発者・インフラ担当者それぞれが取るべき対策まで、現場で使えるレベルで解説します。

HTTPメソッド改ざんとは？なぜ危険なのか

HTTPは「どのような操作をするか」をメソッド（動詞）で表現します。代表的なのはGETとPOSTですが、プロトコルにはほかにも多くのメソッドが定義されています。

・GET: リソースの取得（URLを指定してデータを読み込む）
・POST: データ送信・リソースの作成
・PUT: リソースの更新・置換
・DELETE: リソースの削除
・PATCH: リソースの部分更新
・HEAD: レスポンスヘッダーのみ取得（本文なし）
・OPTIONS: サーバーが対応するメソッドの一覧取得
・TRACE: ループバックテスト（デバッグ目的・現在は多くのサーバーで無効化推奨）

問題が起きるのは、Webアプリの認証・認可ロジックが「GETとPOST」だけを想定して設計されているときです。攻撃者がPUTやDELETE、HEADなど別のメソッドを送信すると、認証チェックをそもそも経ないコード分岐に入り込んでしまうことがあります。これがHTTPメソッド改ざんの本質です。

OWASPは長年にわたってこの問題を指摘しており、現在はアクセス制御の不備（Broken Access Control）の一形態として位置づけられています。「認証はある、でも特定の方法で届いたリクエストには効いていない」という状態が生まれやすいのが、この脆弱性の厄介な点です。

攻撃の仕組み：敵が狙う3つのパターン

実際の攻撃シナリオを見てみましょう。

1. 認証バイパス（未認証でリソース操作）

あるWebアプリで管理者向けAPIエンドポイントが以下のように実装されているとします。

# 正規リクエスト（POSTに認証チェックあり）
POST /api/admin/users/42 HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

# 攻撃者の改ざんリクエスト
DELETE /api/admin/users/42 HTTP/1.1
# Authorizationヘッダーなし

# DELETEメソッドの処理に認証チェックが抜けていると削除が成功してしまう

フレームワークのルーティング設定でGET・POSTのみに認証フィルタを適用し、他のメソッドの処理に認証を付け忘れているケースで、このような事故が起きます。「POSTで書き込む機能」の認証を実装しても、「DELETEで削除する経路」を忘れていれば意味がありません。

2. HEADメソッドを使ったアクセス制御迂回

HEADはGETと同じコード経路を通ることが多く、実質「本文なしのGET」として動作するWebサーバーがあります。アクセス制御ルールが「GETは要認証」と定義されていても、HEADリクエストに同じチェックが適用されない設定ミスが存在します。

# HEADリクエストで認証なしにヘッダー情報が返ってくる例
HEAD /admin/config HTTP/1.1
Host: example.com

# 攻撃者が受け取るレスポンス（本文なし・ヘッダーに情報漏洩）
HTTP/1.1 200 OK
X-App-Version: 2.3.1-internal
X-Environment: staging
X-DB-Host: db01.internal

本文を返さないため「安全」に見えますが、レスポンスヘッダーに内部環境情報が含まれるケースでは、攻撃者の偵察に活用されます。

3. OPTIONSメソッドによる攻撃下見とTRACE悪用

OPTIONSリクエストに対してサーバーが「Allow: GET, POST, PUT, DELETE, TRACE」などと返答してしまうと、攻撃者は利用可能なメソッドの全体像を把握し、次の攻撃を計画できます。

TRACEが有効な場合はクロスサイトトレーシング（XST）にも悪用されます。この攻撃では、XSSと組み合わせることでHTTPOnlyフラグで保護されたCookieが窃取される可能性があります。TRACEは現代のWebシステムに業務上の必要がない限り、必ず無効化すべきメソッドです。

具体的な防御手順

1. Webフレームワーク側で許可メソッドを明示的に制限する

最も根本的な対策は、ルーティング定義で使うメソッドを明示し、それ以外を拒否することです。認証・認可のチェックを「どのメソッドで来ても必ず実行する」設計にすることが重要です。

Spring Security（Java）の例

// 管理者エンドポイントはGET・POSTのみ許可し、他は全拒否
http.authorizeHttpRequests(auth -> auth
    .requestMatchers(HttpMethod.GET, "/admin/**").hasRole("ADMIN")
    .requestMatchers(HttpMethod.POST, "/admin/**").hasRole("ADMIN")
    .requestMatchers("/admin/**").denyAll()  // PUT/DELETE/PATCHなどは全拒否
    .anyRequest().authenticated()
);

Django（Python）の例

from django.views.decorators.http import require_http_methods

# GETとPOSTのみ受け付けるデコレータで明示する
@require_http_methods(["GET", "POST"])
@login_required
def admin_view(request):
    ...

Laravel（PHP）の例

// ルート定義でメソッドを明示する（Route::any() は使わない）
Route::get('/admin/users', [AdminController::class, 'index'])->middleware('auth');
Route::post('/admin/users', [AdminController::class, 'store'])->middleware('auth');
// 上記以外のメソッドは自動的に405 Method Not Allowedになる

共通して言えるのは、認証チェックをメソッドのif分岐の中に閉じ込めないこと。「POSTなら認証する」ではなく「このエンドポイントに到達したら必ず認証する、そのうえで許可メソッド以外は拒否する」という順序が正しい設計です。

2. Webサーバー（Apache・Nginx）で不要なメソッドを無効化する

アプリケーション側の対策に加え、Webサーバーレベルでも不要なメソッドを弾く設定を入れておくことで、防御の層を重ねられます。

Apache（httpd.conf または .htaccess）

# GET・HEAD・POST以外を403で拒否する
<LimitExcept GET HEAD POST>
    Require all denied
</LimitExcept>

# TRACEメソッドを明示的に無効化（古いApacheはデフォルトで有効）
TraceEnable Off

Nginx（nginx.conf の server ブロック内）

server {
    # GET・HEAD・POST以外は405 Method Not Allowedを返す
    if ($request_method !~ ^(GET|HEAD|POST)$) {
        return 405;
    }
    # ...残りの設定...
}

なお、REST APIを提供している場合はPUT・PATCH・DELETEも業務上必要なメソッドです。上記をそのまま適用するとAPIが動作しなくなるため、エンドポイントごとに許可するメソッドを精査し、業務上必要な最小限のみを許可するのが原則です。

3. WAFでHTTPメソッドポリシーを設定する

アプリケーション前段にWAFを設置している場合、HTTPメソッドの許可リストをWAFポリシーとして設定できます。業務上不要なメソッド（TRACEやCONNECTなど）はWAFレベルで一括ブロックしておくと、アプリケーション側の設定漏れに対する補完的な防御になります。

WAFで対処できる代表的なメソッド制限：

・TRACE無効化: XSTリスクの根本対策
・CONNECT無効化: HTTPトンネリング悪用の防止
・PUT・DELETE制限: 静的コンテンツサーバーや不要なAPIエンドポイントへの適用
・OPTIONS応答制御: Allowヘッダーを最小化し、攻撃者への情報提供を減らす

中小企業でも今日からできること

フレームワークのコードまで手が回らない現場でも、次の3ステップから始められます。

・TRACEを今すぐ無効化する: ApacheではTraceEnable Off、Nginxではメソッドフィルターを追記するだけです。設定変更5分・効果はすぐに出る対策です。
・OPTIONSレスポンスを確認する: curl -v -X OPTIONS https://（自社サイトURL）/ を実行し、Allowヘッダーに業務上不要なメソッドが含まれていないか確認します。TRACEやCONNECTが見えたら即対処のサインです。
・APIエンドポイントの棚卸しをする: 使っていないエンドポイントに不要なメソッドが残っていないか、年1回のペースでリストアップするだけでも大きなリスク低減になります。

認証・認可の全体設計を見直す際は、OWASP Top 10とセキュアコーディングの基本原則と合わせて読むと体系的に理解できます。また、セキュリティヘッダーの設定もWebサーバー側の防御として合わせて確認しておきましょう。

よくある誤解と注意点

【誤解1】GETしか使っていないサイトだから関係ない

Webサーバーがアクセスを受け付けている以上、POSTやDELETEのリクエストは外部から直接送れます。「サイトのUIからはGETしか使えない」と「サーバーがGET以外のメソッドを処理しない」はまったく別の話です。ブラウザのUIを介さない直接リクエストへの対策が必要です。

【誤解2】「405 Method Not Allowed」を返せばOK

HTTPレスポンスコードが405でも、処理の一部（データベースへの書き込みなど）が先に実行されてから405を返すバグが存在します。「エラーレスポンスを返す前に業務ロジックが走っていないか」をコードレベルで確認することが必要です。レスポンスコードと実際の処理の順序は別物です。

【誤解3】フレームワークが自動で守ってくれる

多くのフレームワークはデフォルトで全メソッドを受け付け、ルーティング定義に従ってディスパッチします。「開発者が使うと宣言したメソッドのみ」に制限が機能するのであって、「設定した覚えはないが何とかなっている」という状態は脆弱な可能性があります。使用するメソッドを明示的に宣言するコーディング習慣を徹底しましょう。

【注意】CSRFとの組み合わせに注意する

HTTPメソッド改ざんはCSRF（クロスサイトリクエストフォージェリ）と組み合わせて悪用されることがあります。CSRFトークンはPOSTリクエストのみに実装されているケースが多く、PUTやDELETEで同じ機能を叩かれた場合にはCSRFトークンのチェックが機能しないことがあります。メソッド制限とCSRF対策は一緒に見直しましょう。

本記事のまとめ

HTTPメソッド改ざん（HTTP Verb Tampering）は、GETやPOST以外のHTTPメソッドを悪用して認証・認可ロジックをすり抜ける攻撃です。シンプルな攻撃手法ながら、認証チェックの設計漏れや設定ミスがあれば未認証の操作が通ってしまいます。

Webアプリの安全性はコードだけでなく、Webサーバー設定・WAF・運用フローの組み合わせで決まります。まずはTRACEメソッドの無効化とOPTIONSレスポンスの確認から、今日の業務終わりにでも取り組んでみてください。