HTTP Methods Scanner

How this check works

Scanaris sends an OPTIONS request to the scanned URL, without following redirects, and reads two response headers: Allow, which a server uses to declare which methods it accepts on that route, and Access-Control-Allow-Methods, the CORS one. If either of them lists TRACE, TRACK, PUT, DELETE or CONNECT, it opens a low-severity finding with the list. It is a conservative check: it only flags what the server explicitly announces. It never sends a test PUT or DELETE, and if the server does not answer the OPTIONS or does not return those headers, there is no finding.

Why it matters

A normal website needs GET, HEAD, POST and, for CORS, OPTIONS. The rest are methods with a history. TRACE echoes the request back exactly as received, headers included; combined with another flaw it allows reading cookies marked HttpOnly (the attack is called Cross-Site Tracing). PUT and DELETE create, replace or remove resources: on a misconfigured file server, a PUT uploads a file into the public directory. CONNECT turns the server into a proxy. Being enabled does not mean they work without authentication, hence the low severity; but announcing them without using them is free attack surface.

How to fix it

• Apache: TraceEnable Off in the main configuration (TRACE is on by default in older versions). For the rest, inside your site's Directory or Location: <LimitExcept GET POST HEAD OPTIONS> Require all denied </LimitExcept>.
• nginx: does not implement TRACE. To limit the rest in a location block: limit_except GET POST HEAD OPTIONS { deny all; }. If you use if ($request_method !~ ^(GET|HEAD|POST|OPTIONS)$) { return 405; }, put it at server level.
• IIS: the WebDAV module is the usual reason PUT and DELETE are announced. Uninstall it if you do not use it, and in web.config restrict verbs with requestFiltering/verbs.
• Express and APIs: if your API uses PUT or DELETE with authentication, it is legitimate for Access-Control-Allow-Methods to list them; what it should not do is list them across the whole site or use *. In the CORS middleware, set methods: ['GET', 'POST'] on public routes and widen only where needed.
• Vercel, Netlify, Cloudflare Pages: do not announce these methods by default. If the finding appears, it usually comes from a CORS header you configured yourself with the full list.

Check it is fixed

curl -si -X OPTIONS https://yourdomain.com | grep -iE "^(HTTP|allow|access-control-allow-methods):"
curl -si -X TRACE https://yourdomain.com | head -1

In the first, neither Allow nor Access-Control-Allow-Methods should include TRACE, TRACK, PUT, DELETE or CONNECT on public routes. The second must return 405 or 403, never 200 with your request echoed in the body.

Frequently asked questions

My REST API uses PUT and DELETE. Do I have to remove them?

No. What matters is that those routes require authentication and that the CORS header does not announce them for the whole domain or for any origin. If the scan points at the root of your API, you can mark the low-severity finding as accepted once you have checked that. Origin configuration is reviewed by permissive CORS.

Access-Control-Allow-Methods lists methods, but there is no Allow. Is it the same?

Not quite. Allow describes what the server accepts; the CORS header describes what it permits to pages from other origins. Both are read because both are information you give away. What each part of a CORS response means is explained in misconfigured CORS.

Why is OPTIONS not considered dangerous?

Because it is the method the browser uses to ask about CORS before certain requests. Blocking it breaks cross-domain calls. It is harmless and necessary.