HTTP Methods Exposure Checker Guide: Find the Verbs Your Server Should Not Offer

Every web request carries a verb, called an HTTP method, that says what the client wants to do: read something, submit something, replace something, or remove something. Most visitors only ever use two verbs, GET to read a page and POST to submit a form. But a server, by default, may accept many more, and each accepted verb is a capability offered to anyone who asks. A server that accepts TRACE lets a client bounce its own request back and read the headers, which can aid attacks. A server that accepts PUT or DELETE on public paths may let a stranger upload or remove content. The HTTP Methods Exposure Checker reads a method list you paste, such as the Allow header from a response, and flags the verbs that are risky to leave open. It works on pasted text: it judges the list you show it, it does not probe your live server, and a clean list does not prove the server enforces it on every path.

The common methods are worth knowing by name. GET retrieves a resource and should never change anything. HEAD retrieves only the headers of a resource, useful for checking existence without downloading. POST submits data, such as a form, and may change state. PUT replaces a resource at a given address with new content. DELETE removes a resource. PATCH applies a partial change. OPTIONS asks the server which methods and features it supports, and is how a method list is usually discovered. TRACE echoes the received request back to the client, which was designed for debugging. Less common verbs include CONNECT, used for tunnels, and the legacy TRACK, a variant of TRACE. A typical public website needs GET, HEAD, POST, and OPTIONS, and little else, on its public paths; an API may legitimately need PUT, PATCH, and DELETE, but only behind authentication and authorisation, never open to anonymous clients.

Why open methods are dangerous

The danger is not the verb itself but the combination of verb and access. TRACE is dangerous because it reflects request headers back, including cookies and authorisation values in some configurations, and that reflection has been used to steal credentials in cross-site attacks. That is why TRACE is almost never needed on a production server and should be disabled. PUT is dangerous on a public path because it lets anyone store content at an address, which has been used to deface sites and plant malicious files. DELETE is dangerous for the obvious reason: it removes content, and an unauthenticated DELETE on a content path is a vandal's invitation. OPTIONS is less dangerous on its own, since it only reports capabilities, but it is how an attacker learns which of the dangerous verbs are available, which is why the method list itself is sensitive information to review. The pattern to remember is simple: every verb you leave open is a verb an attacker can use, so leave open only the verbs your application genuinely needs on that path.

Worked example

Take a sample Allow header, with values clearly labelled as an illustration: GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE. That is 7 methods, of which 3 are high-risk on a public path: PUT, DELETE, and TRACE. The risky fraction is 3 out of 7, about 43 percent, since 3 divided by 7 is roughly 0.429. Now consider the fix: disabling TRACE entirely and restricting PUT and DELETE to authenticated API paths removes all 3 from the public list, leaving 4 methods, GET, HEAD, POST, and OPTIONS, with zero high-risk entries on public paths. The reduction in the public attack surface is therefore 3 methods removed out of 7, about 43 percent fewer verbs offered, and more importantly, the remaining verbs cannot by themselves change or remove content. Suppose the same server also serves an API under a separate path that genuinely needs PUT and DELETE: those verbs remain available there, behind authentication, so the total capability of the system is unchanged for legitimate users while the anonymous surface shrinks to read-and-submit only. That distinction, public path versus authenticated path, is the whole art of method hardening.

Mistakes to avoid

The first mistake is checking the method list on the homepage only and assuming it applies everywhere; different paths can allow different methods, so check API paths, upload paths, and legacy paths separately. The second is disabling a verb the application needs, which breaks legitimate features; always test after changing method settings. The third is relying on hiding the OPTIONS response rather than actually disabling the verbs: an attacker can simply try the verb, and if it works, the hiding achieved nothing. The fourth is forgetting legacy or debug paths, which sometimes allow extra methods long after the main application was hardened. The fifth is pasting a method list from another server, or from documentation, and treating the result as a report on your own server; always paste the list from your server's real response, and redact any private values that came with it.

Putting it into practice

Review methods as part of server hardening, and re-review after server upgrades, framework changes, and new application deployments, all of which can reset method handling to defaults. Keep a simple rule for public paths: GET, HEAD, POST, and OPTIONS only, with TRACE disabled everywhere, and PUT, PATCH, and DELETE available only on authenticated API paths that check authorisation for every request. Test the change by attempting the disabled verbs yourself, in a staging environment, and confirming they are rejected. For related checks, the HTTP Headers Checker reads the full header set that carries the Allow list, the HTTP Status Code Checker explains the rejection codes you should see, such as 405 for a method not allowed, and the CORS Checker covers the cross-origin rules that interact with OPTIONS. The companion guide on CSP Checker covers another layer of server hardening that pairs with method control.

Key points

  • HTTP methods are the verbs of a request: GET reads, POST submits, PUT replaces, DELETE removes
  • TRACE and TRACK can leak headers and aid cross-site attacks, and are rarely needed
  • PUT and DELETE on a public server can let strangers change or remove content
  • A checker reads a pasted method list, it does not probe a live server or prove it is safe

In short: a server should offer only the verbs its application needs on each path. Disable TRACE, keep PUT and DELETE behind authentication, and check the method list on every path, not just the homepage, because an open verb is an open capability.