HTTP Methods Enumeration

Discover which HTTP methods your web server accepts. Dangerous methods like TRACE, PUT, and DELETE can enable cross-site tracing attacks and unauthorized file manipulation.

Dangerous HTTP Methods

Most web servers only require GET, POST, and HEAD. Additional methods can introduce serious vulnerabilities:

TRACE: Designed for diagnostic loop-back testing, it echoes back the full request including cookies and auth headers — enabling Cross-Site Tracing (XST) attacks that bypass HttpOnly cookie protection.
PUT / DELETE: Allow uploading or deleting files on the server if WebDAV is enabled. Attackers can upload web shells or delete content.
CONNECT: Intended for proxy tunneling. If exposed, allows tunneling arbitrary TCP connections through your server.
Fix: Disable all methods not explicitly required. Configure your web server (LimitExcept in Apache, limit_except in Nginx) to only allow GET POST HEAD OPTIONS.

Our HTTP Methods Enumeration tool probes your server to discover which HTTP verbs it accepts, flagging dangerous methods such as TRACE, PUT, DELETE and the WebDAV verbs that should not be exposed on a normal web server.

What are HTTP Methods?

HTTP methods, also called verbs, tell the server what kind of action a request intends. GET retrieves a resource, POST submits data, PUT replaces one, DELETE removes one, and OPTIONS asks what is permitted.

Ordinary websites need only GET, POST, HEAD and OPTIONS. APIs commonly add PUT, PATCH and DELETE, controlled by the application authorisation logic.

Problems arise when the server itself accepts methods the application never intended. TRACE echoes the request back and was used in cross-site tracing attacks. PUT and DELETE handled at the server level rather than by the application can permit arbitrary file upload or deletion. The WebDAV extensions — PROPFIND, MKCOL, COPY, MOVE — expose an entire filesystem protocol that has no business on a public web server.

Methods declare what action a request intends to perform
Most sites need only GET, POST, HEAD and OPTIONS
TRACE enables cross-site tracing and should always be disabled
Server-level PUT and DELETE can permit arbitrary file manipulation
WebDAV methods expose a filesystem protocol to the internet

Why HTTP Method Enumeration Matters

Unnecessary methods widen the attack surface in ways that are invisible from the application side. A PUT handler enabled at the web server level bypasses your application authorisation entirely — the request never reaches your code.

Method-based access control bypass is a related and common finding. Some frameworks apply authorisation rules to named methods, so a request using an unlisted verb such as HEAD or an arbitrary string may skip the check while still reaching the handler. Knowing exactly which methods a server accepts is the first step in identifying that class of flaw.

Server-level PUT and DELETE bypass application authorisation entirely
TRACE can expose cookies and authentication headers to script
Unlisted methods sometimes bypass framework access control rules
WebDAV verbs expose file operations that were never intended to be public
Method enumeration is a standard early step in any assessment

How This HTTP Methods Checker Works

The tool sends an OPTIONS request and then probes individual methods to see which are genuinely accepted.

Validates the URL input against format and SSRF safety checks
Sends an OPTIONS request and reads the Allow header
Probes each method individually, since the Allow header is often inaccurate
Records the status code returned for each verb
Flags dangerous methods that the server accepts

How to Use the HTTP Methods Checker

Enter the URL you want to test
Run the scan to probe the supported methods
Review which verbs return a success or non-rejection status
Confirm TRACE is disabled
Disable any method the application does not require and re-test

Understanding Your HTTP Methods Results

Each method is probed separately. Here is how to read the findings:

Field / Value	Meaning
`GET and HEAD`	Expected on every web server. HEAD returns the headers of a GET response without the body, and is used by caches and monitoring.
`POST`	Expected wherever forms or APIs accept data. Normal and necessary.
`OPTIONS`	Reports which methods are permitted and is required for CORS preflight requests. Generally safe, though it does disclose the method list.
`TRACE`	Echoes the request back to the client. Used in cross-site tracing attacks to read cookies and auth headers. It has no legitimate production use — disable it.
`PUT and DELETE`	Legitimate for REST APIs where the application handles them. Dangerous when the web server handles them directly, which can permit arbitrary file upload or deletion.
`WebDAV methods`	PROPFIND, MKCOL, COPY, MOVE and LOCK. These expose a filesystem protocol and should never be reachable on a public web server unless WebDAV is deliberately in use.
`Arbitrary verbs`	If the server responds normally to an invented method name, it may be passing unrecognised verbs through to the application, which is a common route to access control bypass.

Common Problems & How to Fix Them

TRACE echoes the full request including headers, which historically allowed script to read cookies marked HttpOnly through cross-site tracing.

In Apache, set TraceEnable Off. In nginx, TRACE is not supported by default but should be explicitly rejected if a proxy is in front. On IIS, remove the verb through request filtering. There is no legitimate reason to keep it.

If the web server handles these rather than passing them to your application, an attacker may be able to upload or remove files directly, bypassing every application control.

Disable WebDAV modules, and restrict permitted methods explicitly. In nginx use a limit_except block; in Apache use the LimitExcept directive. For a REST API, ensure the application receives and authorises these methods rather than the server acting on them.

PROPFIND, MKCOL, COPY and MOVE expose filesystem operations over HTTP and are a frequent source of serious findings.

Disable the WebDAV module entirely unless it is deliberately in use. In Apache that means disabling mod_dav and mod_dav_fs; on IIS, remove the WebDAV publishing feature.

Servers commonly advertise a method list that differs from what they actually accept, in both directions. Relying on OPTIONS alone produces both false positives and false negatives.

Probe each method individually, which is what this tool does. Correct the Allow header afterwards so it reflects the real configuration.

A server that responds normally to an invented verb is likely passing unknown methods through to the application, which can bypass authorisation rules written against a named list of methods.

Configure an explicit allowlist of permitted methods at the server or proxy level, rejecting everything else before it reaches the application.

Best Practices

Allow only the methods your application actually requires
Disable TRACE on every server without exception
Disable WebDAV modules unless WebDAV is deliberately in use
Enforce the method allowlist at the proxy or web server, not only in application code
Ensure authorisation logic covers every method, including HEAD and OPTIONS
Re-test after any server configuration change or platform migration
Apply the same restrictions to staging and internal environments

Security Recommendations

Treat a server-level PUT or DELETE handler as a potential arbitrary file write, and verify it immediately
Never rely on the Allow header alone, since it frequently misrepresents what the server accepts
Check that authorisation rules apply to unlisted and arbitrary verbs, not just the ones enumerated in configuration
Remember HEAD requests often reach the same handler as GET, so any GET authorisation must cover HEAD too
Audit API endpoints individually, since method restrictions are commonly applied inconsistently across routes
Reject unknown methods at the edge rather than passing them through to the application

Frequently Asked Questions

For a typical website, GET, POST, HEAD and OPTIONS. REST APIs additionally need PUT, PATCH and DELETE, handled and authorised by the application. Everything else should be rejected.

TRACE echoes the entire request back, including headers and cookies. In cross-site tracing attacks this was used to read cookies that JavaScript could not otherwise access. It has no legitimate production use.

It is safe when your application receives them and applies proper authorisation. It is dangerous when the web server handles them directly, because the request never reaches your access control logic and may write or delete files on disk.

Extensions such as PROPFIND, MKCOL, COPY, MOVE and LOCK that turn HTTP into a filesystem protocol. They should not be reachable on a public web server unless WebDAV is deliberately in use, and their presence is a common serious finding.

The Allow header is often static or generated by a module that does not reflect the real configuration. It can both overstate and understate reality, which is why methods should be probed individually.

Yes. Some frameworks apply access control rules to a named list of methods, so a request using an unlisted verb may skip the check while still reaching the handler. Enumerating accepted methods is how this class of flaw is found.

In nginx use a limit_except block within the location. In Apache use LimitExcept, and set TraceEnable Off. On IIS use request filtering to remove verbs. Enforcing the allowlist at a reverse proxy covers everything behind it uniformly.