# Dangerous HTTP Methods Explained: When PUT, DELETE, TRACE, and OPTIONS Become a Security Risk

Canonical: https://vulnify.app/blog/dangerous-http-methods-put-delete-trace-options-security

Learn when HTTP methods such as PUT, DELETE, TRACE, OPTIONS, HEAD, and method overrides create real security risk, and how to enforce least-privilege method policies safely.

HTTP methods are the verbs that tell a web server what a client wants to do. Most people are familiar with GET and POST because they sit behind ordinary page loads and form submissions. Modern applications, however, regularly use a wider set of methods including PUT, PATCH, DELETE, OPTIONS, HEAD, and sometimes CONNECT. These methods are not vulnerabilities by themselves. The risk appears when a server exposes methods that the application does not need, applies authorization inconsistently, accepts unexpected method overrides, or lets a privileged action occur through a route that was never meant to be public. This distinction matters because simplistic hardening advice can be just as misleading as ignoring the issue. A REST API may legitimately require PUT or DELETE. A browser may legitimately send OPTIONS before a cross-origin request. HEAD is normal on many web servers. The goal is not to disable every method except GET and POST. The goal is to enforce the smallest set of methods required for each endpoint and apply the same authentication, authorization, validation, and logging expectations to every permitted path. What HTTP methods do HTTP defines method semantics so clients and servers can communicate intent. Common examples include: GET: retrieve a representation of a resource. HEAD: retrieve response metadata without the response body. POST: submit data for processing or create an action whose semantics are defined by the application. PUT: create or replace the state of a resource at a target URI, depending on application design. PATCH: apply a partial modification to a resource. DELETE: request removal of a resource. OPTIONS: discover communication options and, in browsers, support CORS preflight behavior. TRACE: perform a diagnostic loop-back of a request. CONNECT: establish a tunnel, commonly used by proxies. The important security question is not whether a method sounds powerful. It is whether the server should accept that method on that specific endpoint, under those specific credentials, with the expected authorization and validation controls. Why unexpected methods create risk OWASP's Web Security Testing Guide recommends enumerating supported HTTP methods and testing whether alternative methods can bypass controls. The reason is architectural. Security rules are often implemented at several layers: CDN, reverse proxy, web server, framework, middleware, application route, and API gateway. If those layers disagree about which methods are allowed, a request can sometimes reach code through a path that the security designer did not anticipate. Common failure patterns include: A reverse proxy blocks POST to an administrative route but fails to apply the same rule to another accepted method. A framework routes HEAD to the same handler as GET while access-control logic only checks the literal GET method. PUT or DELETE is enabled globally even though only a small API namespace needs it. An application accepts method-override headers that bypass an upstream method restriction. OPTIONS reveals a broader method set than the team intended to expose. TRACE remains enabled even though nobody uses it operationally. A legacy WebDAV or deployment feature leaves write-capable methods available on public paths. These are configuration and authorization problems, not evidence that the HTTP specification itself is unsafe. PUT: legitimate for APIs, dangerous when write access is unintended PUT is commonly used in REST-style APIs to create or replace a resource at a known URI. That is legitimate when the endpoint is designed for it and the caller is properly authorized. The risk appears when PUT reaches a location where anonymous users should never be able to write, replace, or create content. Older server configurations, WebDAV features, storage gateways, or permissive routing rules can accidentally expose write behavior. If a public endpoint accepts a state-changing PUT without appropriate authorization, the issue is not merely that "PUT is enabled." The issue is unauthorized modification. Good controls include: Allow PUT only on routes that require it. Require authentication before state-changing operations. Apply object-level authorization so users can modify only resources they are permitted to control. Validate content type, size, schema, and destination. Prevent arbitrary writes into executable or publicly served directories. Log state-changing requests and investigate unusual volume or targets. Disabling PUT globally may be appropriate for a conventional website that never uses it, but it may break a legitimate API. Scope the control to actual application requirements. DELETE: the method is not the authorization model DELETE is normal for APIs that allow users or administrators to remove resources. The server should not treat the presence of a DELETE request as authorization to perform the action. Authentication establishes who the caller is; authorization decides whether that caller may delete the specific object. A robust API should enforce the same access-control model regardless of how the request reaches the route. If user A can change an object identifier and delete user B's record, the core problem is broken object-level authorization. Blocking DELETE at a firewall might hide one route to the weakness without fixing the application's authorization logic. When DELETE is not used anywhere on a public site, denying it reduces unnecessary attack surface. When it is required, restrict it by route and identity, return clear method errors where it is not supported, and log destructive actions so they are traceable. TRACE: a diagnostic method that is usually unnecessary on public applications TRACE returns a representation of the received request for diagnostic purposes. Historically, it became associated with Cross-Site Tracing discussions because reflected request information could interact badly with older browser capabilities and other vulnerabilities. The modern risk profile is more nuanced than older guidance sometimes suggests. Browser restrictions have changed, and classic demonstrations from early web-security research do not map directly onto every current browser environment. Even so, most public web applications do not need TRACE. If there is no operational requirement, disabling it is a sensible least-privilege decision because it removes a diagnostic feature from the exposed surface. The key point is not to describe TRACE as an automatic critical vulnerability. Treat unexpected TRACE support as configuration hygiene that deserves review, especially if sensitive request headers can be reflected in environments where the method is reachable. OPTIONS: often necessary, especially for CORS OPTIONS is frequently misunderstood because scanners may report that it is enabled. For many modern applications, that is completely normal. Browsers use OPTIONS for CORS preflight requests when a cross-origin request uses certain methods, headers, or content types. An OPTIONS response may include an Allow header or CORS-related headers describing what the endpoint accepts. That information can help defenders inventory the intended surface and can also help attackers understand it, but information disclosure alone does not mean the endpoint is exploitable. Do not disable OPTIONS blindly on an API that relies on browser-based cross-origin requests. Instead: Confirm the methods advertised are actually required. Make sure preflight behavior matches the intended CORS policy. Do not use a permissive CORS policy simply to make browser errors disappear. Apply method restrictions at the endpoint level rather than assuming one global list fits every route. Vulnify's CORS Checker is useful when OPTIONS behavior is part of a broader cross-origin configuration review. HEAD: common, but still part of the access-control surface HEAD is designed to return the headers that a corresponding GET request would return, without the response body. Many servers and frameworks support it automatically. That is useful for cache validation, monitoring, metadata checks, and other normal behavior. The security concern is consistency. If an application protects GET but routes HEAD through a code path that bypasses the same authorization or rate limiting, the method difference can create unexpected behavior. This is one reason security testing should compare methods rather than merely checking whether a method appears in an Allow header. Method override headers can create hidden paths Some frameworks and APIs support method overriding for clients or intermediaries that cannot send certain verbs directly. Common header names include X-HTTP-Method-Override and similar variants. The feature may be legitimate, but it creates another place where layers can disagree. Imagine an edge rule that blocks direct DELETE requests, while the application accepts a POST with a method-override header and internally treats it as DELETE. If authorization is implemented correctly, the request should still be safe. If the organization relied on the edge rule as the only protection, the override can undermine the intended control. Review whether method overriding is actually needed. If it is not, disable it. If it is required, apply authorization after the effective method is resolved and make sure gateways, middleware, and application code share the same interpretation. How to check HTTP methods safely Method discovery should begin with non-destructive requests. An OPTIONS request can provide a useful first view: OPTIONS /api/resource HTTP/1.1 Host: example.com A server might respond with something like: HTTP/1.1 200 OK Allow: GET, HEAD, OPTIONS If a method is not allowed for a resource, 405 Method Not Allowed is the expected HTTP status in many implementations. However, OWASP notes that OPTIONS can be incomplete or inaccurate and method support can vary by path. A root path that rejects DELETE does not prove every API path rejects it. State-changing methods deserve caution during testing. Do not send PUT, DELETE, PATCH, or other potentially destructive requests against systems you do not own or have explicit authorization to test. Even on an authorized system, prefer staging or controlled targets when you are validating write behavior. For a focused external review, Vulnify's HTTP Methods Checker maps methods across endpoints, looks for dangerous verb exposure, and helps teams review least-privilege method policy. It is intended to help identify unexpected surface without turning a simple configuration check into uncontrolled destructive testing. Build a least-privilege method policy The most reliable design is endpoint-specific. For each route family, define which methods are valid and deny the rest. / GET, HEAD /login GET, POST /api/profile GET, PATCH /api/orders GET, POST /api/orders/{id} GET, DELETE /health GET, HEAD The exact policy will differ by application, but writing it down makes drift visible. A reverse proxy, API gateway, or framework can then enforce the same intent. This also makes security reviews easier. Instead of asking, "Is DELETE enabled on the server?" ask, "Where is DELETE permitted, who can use it, what objects can they delete, and what evidence is logged?" That is a much more useful security question. Check every layer that can interpret the method Modern request paths often pass through several components before reaching application code. A CDN may terminate TLS, a WAF may filter requests, a reverse proxy may rewrite routes, an API gateway may enforce policy, and a framework may perform its own method routing. Configuration drift between these layers creates risk. After proxy migrations, framework upgrades, new API gateways, or route refactoring, re-run method checks. Vulnify positions the HTTP Methods Checker specifically for infrastructure, API, and application teams reviewing public endpoints after changes like these. Also review related exposed surface. An unexpectedly reachable administrative or backup path may matter more than the method itself. The Exposed Paths Checker can help identify publicly reachable sensitive paths, while the CORS Checker can validate cross-origin policy around API endpoints. Common mistakes when hardening HTTP methods Mistake 1: Disable everything except GET and POST This can break legitimate REST APIs, CORS preflight, monitoring, and application behavior. Restrict unnecessary methods, but base the policy on route requirements. Mistake 2: Treat OPTIONS as a vulnerability by itself OPTIONS is often legitimate. Review what it exposes and whether the advertised methods are appropriate. Mistake 3: Use the WAF as the only authorization layer Edge method blocks are defense in depth, not a replacement for application authorization. The application should remain safe if a request reaches it through another route or override mechanism. Mistake 4: Assume a 200 response proves a dangerous action occurred Some frameworks return generic responses for methods they do not meaningfully implement. Validate behavior, not just status codes, while staying within authorized, non-destructive testing boundaries. Mistake 5: Test only the home page Method policy frequently differs between the website root, API routes, upload handlers, admin paths, and legacy services. Review representative endpoints. HTTP method security checklist Document the methods required for each route family. Deny unnecessary methods at the most appropriate layer. Require authentication for privileged state-changing operations. Enforce object-level authorization for PUT, PATCH, DELETE, and other write actions. Review HEAD and alternative methods for access-control consistency. Disable TRACE when there is no operational requirement. Keep OPTIONS where required, but verify the advertised and CORS behavior. Review method-override features and disable them when unnecessary. Align CDN, WAF, proxy, gateway, framework, and application method handling. Log state-changing requests and monitor unusual patterns. Re-test after infrastructure and framework changes. Use destructive method testing only on systems you own or are explicitly authorized to assess. How Vulnify fits into the workflow Start with the HTTP Methods Checker when the immediate question is which methods are exposed and whether the public policy appears broader than necessary. If the application uses browser-based cross-origin APIs, follow with the CORS Checker . If legacy or administrative routes may also be exposed, use the Exposed Paths Checker . Those tools answer focused questions. When you need broader application coverage, use the Website Security Scanner to review other public-surface issues such as injection, headers, TLS, cookies, redirects, CORS, technology disclosure, and exposed sensitive paths. Method policy is one part of website security, not a substitute for the rest of the assessment. Conclusion PUT, DELETE, TRACE, and OPTIONS are not inherently dangerous simply because they are less familiar than GET and POST. Risk comes from unnecessary exposure, inconsistent authorization, method confusion between infrastructure layers, and state-changing behavior that is reachable without the controls the application intended. Use least privilege at the endpoint level. Keep the methods your application genuinely needs, deny the ones it does not, and apply authentication and authorization after the server has resolved the effective request method. Then verify the deployed behavior from the outside. That combination is more accurate and more secure than relying on a blanket rule that every uncommon HTTP verb should be disabled.