危険なHTTPメソッド：TRACE、PUT、DELETEが公開される仕組み
HTTPサーバーはOPTIONSリクエストに応答することで、サポートするメソッドを公開できます。そのリストに本番環境で不要なTRACE、PUT、DELETE、PATCH、CONNECTなどの危険なメソッドが含まれると、攻撃者に潜在的な侵入口のマップを渡すことになります。AppSafeはサイトのルートURLにOPTIONSリクエストを送信し、AllowヘッダーまたはAccess-Control-Allow-Methodsヘッダーで見つかった危険なメソッドをフラグします。
これは何か
HTTPサーバーはOPTIONSリクエストに対し、受け付けるメソッドを列挙したAllowヘッダーを返せます：GET、POST、HEAD、OPTIONS、その他サポートするメソッド。フレームワークやリバースプロキシによっては同じレスポンスにAccess-Control-Allow-Methodsを追加します。これらのヘッダーは必須ではありませんが、存在する場合は呼び出し元にどのHTTP動詞を試すべきかを正確に伝えます。
AppSafeはオリジンにOPTIONSリクエストを送信し、両ヘッダーでTRACE、PUT、PATCH、DELETE、CONNECTという危険なメソッドリストを確認します。TRACEは単独で高深刻度の検出として扱われ、その他は中深刻度にまとめられます。この検査は公開内容のみを対象としています。Allowに列挙されたメソッドが実際にサーバー上で何かを行うかどうかに関わらず、列挙自体が探索を促します。
なぜ重要か
TRACEが最も深刻です。リクエスト全体（すべてのヘッダーを含む）を送信者にそのまま返します。資格情報やセッションCookieがリクエストヘッダーとして渡される環境では、クロスサイトトレーシング（XST）を通じてページ内スクリプトにそれらの値が露出する恐れがあります。現代のブラウザはXHR/fetchからのTRACEをブロックしますが、プロキシやロードバランサーはそうでない場合があります。TRACEは本番環境での正当な用途がありません：完全に無効にしてください。
PUT、DELETE、PATCH、CONNECTが問題なのは、公開することでテストを誘発するからです。書き込み可能なパスへのPUTはサーバーに任意のファイルを置ける可能性があります（WebDAVサーバーが典型例）。認証のないDELETEはリソースの削除を許す可能性があります。たとえこれらのメソッドがアプリの認可ロジックを通っており安全であっても、Allowヘッダーに列挙することで攻撃者の調査対象リストを絞り込んでしまいます。
直し方
serverブロックレベルでTRACEをブロックし、アプリが実際に使用するメソッド以外には405を返します。
server {
# Reject TRACE completely
if ($request_method = TRACE) {
return 405;
}
location / {
limit_except GET HEAD POST OPTIONS {
deny all;
}
# ... your proxy_pass or root ...
}
}Expressでは許可リスト外のメソッドを拒否するミドルウェアを追加します。Next.jsのRoute Handlerでは処理するメソッドの関数のみをエクスポートします。フレームワークはそれ以外のメソッドに自動的に405を返します。
// Express: block anything outside the allowlist early
import express from "express";
const app = express();
app.use((req, res, next) => {
const allowed = new Set(["GET", "HEAD", "POST", "OPTIONS"]);
if (!allowed.has(req.method)) {
res.set("Allow", [...allowed].join(", "));
return res.status(405).json({ error: "Method Not Allowed" });
}
next();
});
// Next.js Route Handler — only exported functions are reachable
// (no DELETE export → Next.js returns 405 automatically)
export async function GET(request: Request) {
return Response.json({ ok: true });
}
// export async function DELETE(...) — don't export this unless you need itサーバー更新後、AllowヘッダーにTRACEやPUTなどの危険なメソッドが含まれないことを確認します。
curl -sI -X OPTIONS https://example.com/ | grep -i allow
# Expected: Allow: GET, HEAD, POST, OPTIONS
# If TRACE, PUT, DELETE, PATCH, or CONNECT appear, the restriction didn't land.FAQ
TRACEがブロックされているのに、なぜAppSafeがフラグを立てるのですか？
AppSafeはOPTIONSレスポンスのAllowヘッダーを読み取ります。実際に実行されることではなく、サーバーが公開している内容をフラグします。サーバーはファイアウォールルールでメソッドをブロックしながら、AllowヘッダーでTRACEのサポートを宣言することがあります。AllowヘッダーからTRACEを削除することが正しい修正です。ヘッダー自体が攻撃者が読むシグナルだからです。
AllowヘッダーでPUTを公開すると、ファイルアップロードの脆弱性があるということですか？
必ずしもそうではありません。PUTは認証を必要とし、拒否するハンドラーにルーティングされるか、何もしない可能性があります。リスクはテストを誘発することです。認証されていない呼び出し元からのPUTが不要であれば、AllowレスポンスからPUTを削除してください。
AppSafeはどのように検出しますか？
AppSafeはサイトのルートURLにHTTP OPTIONSリクエストを送信し、AllowヘッダーとAccess-Control-Allow-Methodsレスポンスヘッダーを読み取ります。TRACE、PUT、PATCH、DELETE、CONNECTが表示された場合、検出が報告されます。TRACEは高深刻度、その他は中深刻度でフラグされます。