위험한 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를 추가합니다. 이 헤더들은 필수가 아니지만, 존재할 때는 모든 호출자에게 시도할 동사를 정확히 알려줍니다.
AppSafe는 오리진에 OPTIONS 요청을 보내고 두 헤더에서 위험 목록에 있는 메서드를 확인합니다: TRACE, PUT, PATCH, DELETE 및 CONNECT. TRACE는 자체적인 높은 심각도 발견으로 처리되고 나머지는 중간 심각도로 그룹화됩니다. 이 검사는 광고에 관한 것입니다 — Allow에 나열된 메서드가 서버에서 실제로 작동하든 안 하든, 나열하는 것은 탐색을 장려합니다.
왜 중요한가요
TRACE가 가장 심각합니다. 모든 헤더를 포함한 전체 요청을 호출자에게 그대로 반환합니다. 자격 증명이나 세션 쿠키가 요청 헤더로 전달되는 환경에서는, 이 에코를 통해 크로스 사이트 트레이싱(XST)으로 페이지의 스크립트에 이러한 값이 노출될 수 있습니다. 현대 브라우저는 XHR/fetch에서 TRACE를 차단하지만 프록시와 로드 밸런서는 그렇지 않을 수 있습니다. TRACE는 프로덕션에서 합법적인 용도가 없습니다: 완전히 비활성화하세요.
PUT, DELETE, PATCH, CONNECT는 광고하면 테스트를 유발하기 때문에 중요합니다. 쓰기 가능한 경로에 대한 PUT은 서버에 임의 파일을 올릴 수 있습니다 — WebDAV 서버가 대표적인 예입니다. 인증 없는 DELETE는 호출자가 리소스를 제거하도록 허용할 수 있습니다. 이러한 메서드가 애플리케이션의 인증 로직을 통해 안전하게 처리되더라도 Allow 헤더에 포함시키면 공격자의 조사 목록을 좁혀줍니다.
고치는 방법
서버 블록 레벨에서 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 헤더에 더 이상 위험한 메서드가 나열되지 않는지 확인합니다.
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.자주 묻는 질문
TRACE가 차단되어 있는데 AppSafe가 여전히 플래그를 표시하는 이유는 무엇인가요?
AppSafe는 OPTIONS 응답의 Allow 헤더를 읽습니다 — 서버가 실제로 실행하는 것이 아니라 광고하는 것을 플래그합니다. 서버는 방화벽 규칙으로 메서드를 차단하면서 Allow 헤더에서 TRACE 지원을 주장할 수 있습니다. Allow 헤더에서 TRACE를 제거하는 것이 올바른 수정입니다 — 헤더 자체가 공격자들이 읽는 신호이기 때문입니다.
Allow 헤더에서 PUT을 광고하면 파일 업로드에 취약하다는 의미인가요?
반드시 그런 것은 아닙니다 — PUT은 인증을 요구하거나, 거부하는 핸들러로 라우팅되거나, 아무것도 하지 않을 수 있습니다. 위험은 테스트를 유발한다는 것입니다. 앱이 인증되지 않은 호출자로부터 PUT이 필요하지 않다면 Allow 응답에서 제거하세요.
AppSafe는 어떻게 탐지하나요?
AppSafe는 사이트의 루트 URL에 HTTP OPTIONS 요청을 보내고 Allow 및 Access-Control-Allow-Methods 응답 헤더를 읽습니다. TRACE, PUT, PATCH, DELETE 또는 CONNECT가 나타나면 발견이 보고됩니다. TRACE는 높은 심각도로, 나머지는 중간 심각도로 플래그됩니다.