Dangerous HTTP Methods Enabled (PUT / DELETE / TRACE)

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Server Misconfiguration
Typical Severity High
OWASP A05:2021 – Security Misconfiguration
CWE CWE-16 (Configuration), CWE-650 (Permitting HTTP Verbs)
Also known as HTTP Verb Tampering, Cross-Site Tracing (XST), Insecure HTTP Methods
Affected systems Web servers (Apache, Nginx, IIS, Tomcat), reverse proxies, WebDAV-enabled hosts
Relevant standards RFC 9110 (HTTP Semantics), RFC 5789 (PATCH), RFC 4918 (WebDAV)

Overview

The HTTP specification (RFC 9110) defines a set of request methods — commonly called HTTP verbs — each with a distinct intended purpose. While GET and POST are required for ordinary web browsing and form submission, methods such as PUT, DELETE, and TRACE are intended for specific, controlled contexts. When these methods are left enabled on a production web server without strict access controls, they introduce significant attack surface.

  • PUT: Instructs the server to store the request body at a specified URI, effectively allowing file upload or content replacement.
  • DELETE: Instructs the server to remove the resource at the specified URI.
  • TRACE: Echoes the received HTTP request back to the client, intended for diagnostic loop-back testing. It has no legitimate purpose in production environments.
  • CONNECT and OPTIONS (secondary concern): OPTIONS itself is low-risk but reveals which methods are enabled; CONNECT can be abused to proxy traffic through the server.

How it works

An attacker first probes the server — typically with an OPTIONS request — to enumerate the list of accepted HTTP methods returned in the Allow response header. Depending on which dangerous methods are available, different attack vectors open up:

  • PUT-based file upload: If the server accepts PUT and the target directory is writable, an attacker can upload an arbitrary file (e.g., a web shell) directly to the web root. A request like PUT /shell.php HTTP/1.1 with a malicious body can result in remote code execution if the server processes the uploaded file type.
  • DELETE-based content removal: An unauthenticated DELETE request to a valid resource URI will remove the resource from the server, causing denial of service or data loss.
  • TRACE-based Cross-Site Tracing (XST): The TRACE method echoes all request headers — including Cookie and Authorization headers — in its response body. When combined with a cross-domain scripting vector (e.g., a Flash or older browser XHR vulnerability), an attacker can read HttpOnly cookies that would normally be inaccessible to JavaScript, bypassing one of the key protections against session hijacking.
  • WebDAV extension risk: Servers with WebDAV enabled expose additional methods (PROPFIND, MKCOL, COPY, MOVE) that compound the risk of unauthorised filesystem manipulation.
  • Firewall / WAF bypass via verb tampering: Some access control rules are bound to specific HTTP methods. Sending a request with an unexpected or custom method (e.g., HEAD or an arbitrary verb) can bypass method-level ACLs enforced by middleware or web application firewalls.

Business impact

The consequences of exploiting unnecessarily enabled HTTP methods range from complete server compromise to regulatory penalties:

  • Remote Code Execution (RCE): A successful PUT of a server-side script followed by a GET to execute it gives the attacker full control over the web application environment.
  • Data destruction: Unrestricted DELETE access allows mass removal of application content, leading to service outages and unrecoverable data loss.
  • Session hijacking: XST exploitation via TRACE can expose authenticated session tokens, enabling account takeover without user interaction.
  • Compliance violations: Unauthorised data access or modification may trigger breach notification obligations under GDPR, PCI DSS, HIPAA, and similar frameworks.
  • Reputational damage: Public disclosure of a web shell upload or site defacement via PUT carries significant reputational harm.

How to fix it

  1. Disable TRACE globally: TRACE has no valid production use. Disable it at the server level. In Apache, add TraceEnable Off to the server configuration. In Nginx, there is no native TRACE support, but verify no upstream proxy re-enables it. In IIS, remove TRACE from the allowed verbs list in requestFiltering.
  2. Restrict PUT and DELETE to authenticated, authorised contexts only: If your application requires PUT or DELETE (e.g., a REST API), enforce authentication (OAuth 2.0, API keys) and authorisation checks before processing these methods. Never allow them on static file directories.
  3. Disable WebDAV if not required: WebDAV is a common source of dangerous method exposure. Disable the WebDAV module (mod_dav in Apache, WebDAV in IIS) unless there is an explicit operational need.
  4. Use a whitelist of allowed HTTP methods: Configure your web server or WAF to accept only the methods your application actually uses (typically GET, POST, HEAD, OPTIONS). In Apache: use <LimitExcept GET POST HEAD> Deny from all </LimitExcept>. In Nginx: use if ($request_method !~ ^(GET|POST|HEAD)$) { return 405; }. In IIS: use requestFiltering with an explicit verb allowlist.
  5. Apply network-layer controls: Use a Web Application Firewall (WAF) or reverse proxy to reject disallowed methods before they reach the application server.
  6. Verify with OPTIONS enumeration after hardening: After applying changes, send an OPTIONS request to the server and confirm the Allow header lists only the intended methods.
  7. Audit regularly: Include HTTP method enumeration in periodic security assessments and CI/CD pipeline security tests to detect configuration drift.

References

Frequently asked questions

Send an OPTIONS request to your server using curl: `curl -v -X OPTIONS https://yourdomain.com/`. The response will include an `Allow` header listing all accepted methods. Any method beyond GET, POST, HEAD, and OPTIONS (and PUT/DELETE/PATCH only if your API explicitly requires them) should be investigated and likely disabled.

The original Cross-Site Tracing (XST) attack relied on browser-level XMLHttpRequest or Flash capabilities to send TRACE requests cross-domain. Modern browsers block cross-domain TRACE via XMLHttpRequest, reducing the exploitability of XST. However, TRACE still echoes all request headers including credentials in its response body, provides no operational value in production, and should be disabled as a baseline hardening measure regardless of current browser mitigations.

No. PUT and DELETE are legitimate and commonly used HTTP methods in REST API design. The risk arises when these methods are enabled without authentication and authorisation controls, or when they are available on paths that should not allow modification (such as static file directories). Ensure every PUT and DELETE endpoint enforces authentication (e.g., OAuth 2.0 bearer tokens) and fine-grained authorisation before processing the request.

Not necessarily. If your application framework handles TRACE requests itself (rather than the web server), the framework may respond even if the web server is configured to block it. You should disable TRACE at both the web server level and, if applicable, verify that your application framework does not implement a TRACE response handler. Also ensure that any reverse proxy or load balancer in front of your server does not re-enable TRACE.

Sensagraph automatically issues OPTIONS and targeted method probe requests to discovered endpoints and inspects the Allow response header and actual method responses to identify which potentially dangerous HTTP methods the server accepts.