Dangerous HTTP methods: how TRACE, PUT, and DELETE get advertised
HTTP servers can advertise which methods they support by responding to an OPTIONS request. When that list includes dangerous methods — TRACE, PUT, DELETE, PATCH, or CONNECT — that aren't needed in production, you've handed attackers a map of potential entry points. AppSafe sends an OPTIONS request to your root URL and flags any dangerous methods it finds in the Allow or Access-Control-Allow-Methods headers.
What it is
Every HTTP server can respond to an OPTIONS request with an Allow header listing the methods it accepts: GET, POST, HEAD, OPTIONS, plus whatever else it supports. Some frameworks and reverse proxies add Access-Control-Allow-Methods to the same response. Neither header is required, but when present they tell any caller exactly which verbs to try.
AppSafe sends one OPTIONS request to your origin and checks both headers for methods in a short danger list: TRACE, PUT, PATCH, DELETE, and CONNECT. TRACE gets its own high-severity finding; the rest are grouped together at medium. The check is purely about advertisement — a method listed in Allow may or may not actually do anything on your server, but listing it encourages exploration.
Why it matters
TRACE is the most serious. It echoes the full request — including all headers — back to the caller. In environments where credentials or session cookies are passed through as request headers (some proxy configurations, older stacks), that echo could expose those values to a script in the page via cross-site tracing (XST). Modern browsers block TRACE from XHR/fetch, but proxies, load balancers, or indirect paths may not. TRACE has no legitimate production use: turn it off entirely.
PUT, DELETE, PATCH, and CONNECT matter because advertising them invites testing. A PUT that lands on a writable path can drop arbitrary files on the server — WebDAV servers are the classic example. A DELETE that isn't gated by auth can let a caller remove resources. Even when these methods route through your application's own authorization logic and are perfectly safe, having them in the Allow header focuses an attacker's probe list and reduces the work they have to do to find a weak endpoint.
How to fix it
Block TRACE at the server block level and return 405 for any method outside the short list your app actually uses.
server {
# Reject TRACE completely
if ($request_method = TRACE) {
return 405;
}
location / {
limit_except GET HEAD POST OPTIONS {
deny all;
}
# ... your proxy_pass or root ...
}
}In Express you can add a middleware that rejects any method you don't explicitly support. In Next.js Route Handlers, only export the functions for methods you handle — the framework returns 405 automatically for anything else.
// 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 itOnce the server is updated, confirm the Allow header no longer lists the dangerous methods.
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
If TRACE is blocked, why would AppSafe still flag it?
AppSafe reads the Allow header from an OPTIONS response — it flags what the server advertises, not what it actually executes. A server can claim to support TRACE in its Allow header while having blocked the method body behind a firewall rule. Removing TRACE from the Allow header is the right fix because the header itself is the signal attackers read.
Does advertising PUT in the Allow header mean my server is vulnerable to file upload?
Not necessarily — PUT may require authentication, route to a handler that rejects it, or do nothing at all. The risk is that it invites testing. If your app never needs PUT from unauthenticated callers, remove it from the Allow response so attackers don't spend time probing for a weakness that might not exist.
How does AppSafe detect this?
AppSafe sends an HTTP OPTIONS request to your site's root URL and reads the Allow and Access-Control-Allow-Methods response headers. If any of TRACE, PUT, PATCH, DELETE, or CONNECT appear, it reports the finding. TRACE is flagged at high severity; the others at medium.
Is your app affected?
AppSafe checks for this and dozens of other issues in one free scan.
Scan my app freeRelated guides
CORS misconfiguration: the wildcard and reflection traps
Allow every origin and any site can read your API.
Verbose error pages and stack traces in production
A stack trace tells attackers exactly where to aim.
Public GraphQL introspection: why it's a problem and how to turn it off
A single query returns your entire schema. Turn it off in production.
Open directory indexes: when your file server lists everything
A file server that lists its contents hands attackers a free inventory.