OPTIONSが示す不要・危険なHTTPメソッドとは？Allowヘッダーの確認方法・無効化設定・診断基準

OPTIONSが示す不要・危険なHTTPメソッドとは

OPTIONSが示す不要・危険なHTTPメソッドとは、OPTIONS メソッドへの応答に含まれる Allow ヘッダーや Access-Control-Allow-Methods ヘッダーに並ぶメソッドのうち、公開サイトでは通常不要なもの（TRACE、CONNECT、WebDAV系、PUT、DELETE）のことです。

HTTP/1.1 200 OK
Allow: GET,POST,OPTIONS,HEAD,TRACE

セキュリティAIチェッカーのこの項目は、サイトのトップ（オリジン）と、見つかったAPI候補1件に対して OPTIONS メソッドでリクエストし、これらのヘッダーに要確認のメソッドが並んでいないかを確認します。

OPTIONSの応答は「サーバーがこのURLで受け付けると申告しているメソッド」の一覧で、実際の可否とは一致しないことがあります。そのため本項目は×（fail）を出さず、△（warn）にとどめる「参考情報」として扱います。

OPTIONSメソッドとAllowヘッダーの仕組み（RFC 9110）

• RFC 9110では、OPTIONSは対象リソースで利用可能な通信オプションを問い合わせるメソッドで、安全（safe）かつ冪等なメソッドと定義されています（§9.3.7）。
• Allow ヘッダーは対象リソースがサポートするメソッドの一覧を示し、405（Method Not Allowed）応答では必ず付けることになっています（§10.2.1）。
• ただし実際に許可されるメソッドはリクエストごとにサーバーが決めるもので、Allowの内容はあくまで申告です。
• Access-Control-Allow-Methods はCORSのプリフライト応答で使われるヘッダーで、他オリジンのJavaScriptに許すメソッドを示します。

不要・危険なHTTPメソッドはなぜ問題なのか

各メソッドの意味とリスク

現在の主要ブラウザは、JavaScript（XMLHttpRequest / fetch）からTRACEメソッドを送ることを禁止しているため、XSTはブラウザ単体では成立しにくくなっています。それでもTRACEを残す理由はなく、ASVSとIPA（「安全なウェブサイトの作り方」XSSの保険的対策 5-(ix)：HttpOnly付与とTRACEメソッドの無効化）はいずれも無効化を求めています。

標準・ガイドラインの要求

HTTPメソッドについてよくある誤解

• 「AllowにPUTがある＝誰でも書き込める」：多くの場合、実際にはアプリ側の認証・認可で拒否されます。逆に、Allowに出ていなくても実際には受け付けるサーバーもあります。本項目がwarnにとどめるのはこのためです。
• 「OPTIONSを無効にすれば安全」：OPTIONSはCORSのプリフライトで必要です。APIを他オリジンから利用させている場合、OPTIONSを止めると正当な利用が壊れます。止めるべきは不要なメソッドそのものです。
• 「REST APIでPUT/DELETEがあるのは異常」：APIでは正当に使われます。APIのURLでwarnになった場合は、認証・認可が掛かっていることを確認できれば問題ありません。

OPTIONSが示す不要・危険なHTTPメソッドの診断基準（セキュリティAIチェッカー）

取得方法

1. 対象：オリジンのルート（https://ホスト名/）と、API候補の先頭1件（V2診断で見つかった /api/ 配下のURLや .json のURL。なければルートのみ）。
2. OPTIONS メソッドで送信し、リダイレクトは追跡しません。タイムアウト5秒、本文上限20KBです。Origin ヘッダーは付けません。
3. 各応答から Allow と Access-Control-Allow-Methods の値を取り出します。どちらのヘッダーもない応答は判定材料から除外します。

判定条件

ヘッダー値の中から、単語として TRACE、CONNECT、PROPFIND、PROPPATCH、MKCOL、COPY、MOVE、LOCK、UNLOCK、PUT、DELETE を探します（大文字小文字を区別しない）。

• 証拠欄には見つかったメソッド名を重複なく表示します。
• PATCH は対象外です（APIで一般的に使われ、静的ファイル領域で有効化されることが少ないため）。
• Access-Control-Allow-Methods: * のようなワイルドカードは、個別メソッド名を含まないためwarnにはなりません。認証情報を伴うCORSではワイルドカードはメソッド名として扱われない点も含め、CORSの許可範囲は「CORSプリフライトの許可範囲」で別途確認します。
• 実際にTRACEやPUTを送って成功するかの確認は行いません（対象サイトに変更を加えないため）。warnの場合は管理者側で実機確認してください。

自治体サイトでの判定例

不要・危険なHTTPメソッドが有効だとどんなリスクがあるか

• TRACE：XSSなど他の脆弱性と組み合わさった場合に、HttpOnlyで守っているCookieや、プロキシが付加したヘッダーが読まれるおそれがあります。単独での危険度は低いものの、診断報告では指摘されることが多い項目です。
• PUT/DELETE/WebDAV：認可が不十分な場合、Webページの改ざん、悪性ファイルの設置、ファイル削除が可能になります。WebDAV経由の書き込みと実行権限の組み合わせは、Webシェル設置の典型的な経路です。
• 攻撃面の拡大：使っていないメソッドが有効なこと自体が、設定の管理が行き届いていない兆候であり、他の設定不備を探す手がかりを攻撃者に与えます。

不要なHTTPメソッドの無効化方法（Apache・nginx・IIS・Next.js）

Apache

# httpd.conf（サーバー全体。.htaccessでは設定不可）
TraceEnable Off

# .htaccess でも可：必要なメソッド以外を拒否（Apache 2.4）
<LimitExcept GET POST HEAD OPTIONS>
  Require all denied
</LimitExcept>

# WebDAVを使わないならモジュールを読み込まない
# LoadModule dav_module modules/mod_dav.so
# LoadModule dav_fs_module modules/mod_dav_fs.so

TraceEnable の既定値はOnです。TRACEは <Limit>／<LimitExcept> では制限できないため、必ず TraceEnable Off で止めます。.htaccess で <LimitExcept> と Require を使うには、AllowOverride で Limit と AuthConfig が許可されている必要があります。

nginx

nginxは既定でTRACEを405で拒否します。静的配信の場所で使うメソッドを制限するには次のようにします。

location / {
    # GETを許可するとHEADも許可される。CORSを使う場所ではOPTIONSも加える
    limit_except GET POST {
        deny all;
    }
}

limit_except はlocationコンテキストでのみ使えます。WebDAVモジュール（dav_methods）は使わない限り設定しません。

IIS（web.config）

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <verbs allowUnlisted="false">
          <add verb="GET" allowed="true" />
          <add verb="HEAD" allowed="true" />
          <add verb="POST" allowed="true" />
          <add verb="OPTIONS" allowed="true" />
        </verbs>
      </requestFiltering>
    </security>
    <modules>
      <remove name="WebDAVModule" />
    </modules>
    <handlers>
      <remove name="WebDAV" />
    </handlers>
  </system.webServer>
</configuration>

Request Filteringで拒否されたメソッドは404.6（Verb Denied）としてログに記録されます。

Next.js（App Router）

Route Handlerは、エクスポートしたメソッド（GET、POST など）だけを処理し、それ以外には405を返します。不要な PUT・DELETE をエクスポートしないことが基本です。全体で一括制限する例を示します（Next.js 16以降は proxy.ts。15以前は middleware.ts で関数名を middleware にします）。

// proxy.ts
import { NextResponse, type NextRequest } from "next/server";
const ALLOWED = new Set(["GET", "HEAD", "POST", "OPTIONS"]);
export function proxy(request: NextRequest) {
  if (!ALLOWED.has(request.method)) {
    return new NextResponse(null, { status: 405, headers: { Allow: [...ALLOWED].join(", ") } });
  }
  return NextResponse.next();
}

段階的な手順

設定後の確認方法

# 申告されているメソッドを確認
curl -s -o /dev/null -D - -X OPTIONS https://www.example.lg.jp/ | grep -iE '^(allow|access-control-allow-methods):'

# TRACEが拒否されるか（405/403/501などが期待値）
curl -s -o /dev/null -w '%{http_code}\n' -X TRACE https://www.example.lg.jp/

# PUTが拒否されるか（自組織のサイトに限り、存在しないパスで確認）
curl -s -o /dev/null -w '%{http_code}\n' -X PUT --data 'x' https://www.example.lg.jp/miniparse-put-test.txt

サイトを壊さないための注意点

• OPTIONSそのものを拒否すると、CORSを使う外部連携（地図、予約、問い合わせフォームのAPIなど）が動かなくなることがあります。
• LimitExcept の書き方を誤ると、POSTを使うフォームが403になります。問い合わせフォームや検索で動作確認してください。
• CDNやWAFがOPTIONSに独自応答を返している場合、オリジンサーバーの設定と結果が一致しないことがあります。

よくある質問（FAQ）

参考資料

• OWASP ASVS 5.0.0 V4 API and Web Service（4.1.4）
• OWASP ASVS 5.0.0 V13 Configuration（13.4.4）
• OWASP WSTG HTTP Methods（WSTG-CONF-06）
• IPA 安全なウェブサイトの作り方 1.5 クロスサイト・スクリプティング
• RFC 9110 HTTP Semantics
• Apache HTTP Server core（TraceEnable）
• nginx ngx_http_core_module（limit_except）
• Microsoft Learn Request Filtering

「OPTIONSが示す不要・危険なHTTPメソッド」と関連する診断項目

• CORSプリフライトの許可範囲high
• トップページが正常応答high
• 存在しないURLのステータスmedium
• エラー応答のデバッグ情報high
• エラー応答のヘッダー整合性medium
• 外部URLパラメータへのオープンリダイレクトhigh