WebOTG Security Testing Library ● Public reference
W WebOTG
Search
WebOTG
Standards Countries Topics Resources About
WEBOTG SECURITY TESTING PROCEDURE

WebOTG-SM-015 — Insecure HTTP Methods

A structured procedure for identifying HTTP methods that are unnecessarily enabled, improperly restricted or exposed on application endpoints and verifying that only required methods are available.

WebOTG ID SM-015 OWASP A02:2025 Type HTTP Configuration Method HTTP Method Review Version 1.0
01 / OBJECTIVE

Objective

What are we verifying?

Verify that the application, web server and intermediary infrastructure expose only the HTTP methods required for legitimate application functionality.

HTTP defines multiple request methods, but an application does not necessarily need to accept every method on every endpoint. Unnecessary methods can increase the attack surface and, depending on server configuration, may expose unintended functionality.

The assessment must distinguish between a method being technically supported by a server and a method being dangerously usable against an application resource.

Method availability alone is not always a vulnerability

Methods such as OPTIONS, HEAD, PUT, PATCH or DELETE may be legitimately required. The finding should be based on unnecessary exposure, unsafe behavior or a mismatch with the application's intended design.

02 / SCOPE

Scope

Review HTTP methods across:

Public web resources
Authenticated application endpoints
Administrative interfaces
REST and HTTP APIs
File and document management endpoints
Reverse proxies and gateways
Web server virtual hosts
CDN or edge configurations
03 / PREREQUISITES

Prerequisites

Authorization Confirm authorization to send controlled HTTP requests to the application.
Endpoint inventory Identify representative application endpoints and their intended operations.
API documentation Where applicable, review documented methods for API resources.
Infrastructure information Identify web servers, reverse proxies, API gateways and CDNs that may modify method handling.
04 / METHODOLOGY

Methodology

Determine which HTTP methods are accepted by representative endpoints and then establish whether each accepted method is necessary and securely implemented.

Method Purpose
OPTIONS Determine advertised or supported methods and evaluate whether disclosure is appropriate.
PUT / PATCH Determine whether resource modification is intentionally supported and correctly protected.
DELETE Determine whether deletion operations are intentionally exposed and protected by appropriate authorization controls.
TRACE Determine whether the method is enabled when it is not required by the deployment.
CONNECT Verify that proxy infrastructure does not unintentionally expose CONNECT functionality to untrusted clients.
05 / PROCEDURE

Test procedure

01
Select representative endpoints Include normal web pages, authenticated resources, APIs and administrative endpoints where applicable.
02
Establish the expected method set Determine which HTTP methods are legitimately required by each endpoint.
03
Inspect OPTIONS responses Review Allow information and compare advertised methods with documented application behavior.
04
Test individual methods Send authorized requests using methods that are not expected to be supported and observe the resulting behavior.
05
Determine actual impact If an unexpected method is accepted, determine whether it permits meaningful state changes, resource access or other unintended behavior.
06
Review authentication and authorization Verify that supported state-changing methods enforce the same authorization requirements as their intended application operations.
07
Review intermediary infrastructure Confirm that reverse proxies, gateways and web servers do not expose methods beyond the application's intended method set.
06 / HTTP METHODS

HTTP method review

Method Typical purpose Review
GET Retrieve a resource. Normally expected for resources that support retrieval.
HEAD Retrieve response metadata without the response body. Usually legitimate where supported by the web stack.
POST Submit data or request an operation. Review authentication, authorization, validation and CSRF requirements.
PUT Replace or create a resource. Should be enabled only where explicitly required.
PATCH Partially modify a resource. Should be enabled only where explicitly required.
DELETE Delete a resource. Must have appropriate authentication and authorization controls.
OPTIONS Request communication options. Review whether method information is appropriately exposed.
TRACE Diagnostic request loop-back. Disable where not required.
CONNECT Establish a tunnel through a proxy. Ensure it is not unintentionally exposed by proxy infrastructure.

Example request

HTTP request EXAMPLE 
OPTIONS /account/profile HTTP/1.1
Host: example.test
Accept: */*

Example response

HTTP response EXAMPLE 
HTTP/1.1 204 No Content
Allow: GET, HEAD, POST, OPTIONS

The returned method list should be compared with the application's documented behavior. An unexpected method should then be tested to determine whether it actually performs an unintended operation.

07 / ASSESSMENT

Assessment

Condition Assessment consideration
Method rejected Generally expected when the method is not supported by the endpoint.
Method supported and documented Review its authentication, authorization, validation and business logic controls.
Method supported but undocumented Investigate whether the functionality is intentional or an infrastructure configuration artifact.
State-changing method without proper authorization Treat as a potentially significant security issue and investigate the resulting impact.
TRACE unnecessarily enabled Determine whether the method is required; disable it when unnecessary.
08 / EXPECTED RESULT

Expected result

Pass condition

Each endpoint accepts only the HTTP methods required for its documented functionality, and every supported state-changing method is protected by appropriate authentication, authorization and application security controls.

Unsupported methods should be rejected with an appropriate HTTP response rather than being silently mapped to unintended application functionality.

09 / FAILURE CRITERIA

Failure criteria

An unnecessary HTTP method is enabled on an application endpoint.
An unexpected method performs a meaningful application operation.
A state-changing method bypasses expected authentication or authorization controls.
TRACE is unnecessarily enabled on the deployed application.
Proxy infrastructure exposes CONNECT functionality where it is not required.
Method restrictions differ between security-sensitive endpoints without a documented reason.
Example finding METHOD MISCONFIGURATION

A production endpoint intended only for resource retrieval accepts an additional state-changing HTTP method that is not documented or required by the application. The method is processed by the backend and creates unintended application functionality.

10 / REMEDIATION

Remediation

Establish an explicit HTTP method policy for each application endpoint and enforce it at the appropriate application or infrastructure layer.

Recommended approach

  1. Document the HTTP methods required by each application resource.
  2. Disable methods that are not required.
  3. Enforce method restrictions at the appropriate web-server, gateway or application layer.
  4. Ensure state-changing methods enforce authentication and authorization.
  5. Apply request validation to supported methods.
  6. Review CSRF protections for browser-based state-changing requests where applicable.
  7. Disable TRACE where it is not required.
  8. Review proxy configurations for CONNECT and other tunneling behavior.
  9. Keep method handling consistent across application instances and environments.
  10. Re-test after web-server, gateway or application configuration changes.

Example web-server policy

Illustrative configuration EXAMPLE 
# Example policy concept

GET      -> allowed
HEAD     -> allowed
POST     -> allowed where required

PUT      -> explicitly required only
PATCH    -> explicitly required only
DELETE   -> explicitly required only

TRACE    -> disabled
CONNECT  -> not exposed to application clients

Unsupported methods
        -> reject with appropriate HTTP response
Enforce policy at more than one layer when appropriate

Restricting methods only at a reverse proxy may not be sufficient if the backend can be reached through another route. Where architecture permits, enforce the intended method policy at the application layer as well.

11 / VERIFICATION

Verification

01
Review the documented method matrix Confirm which methods are expected for each tested endpoint.
02
Test unsupported methods Send controlled requests using methods that should not be accepted.
03
Verify rejection behavior Confirm that unsupported methods are rejected and do not trigger unintended application processing.
04
Test supported state-changing methods Verify authentication, authorization and request-validation controls.
05
Verify TRACE and proxy behavior Confirm unnecessary diagnostic or tunneling methods are not exposed.
06
Verify configuration persistence Confirm restrictions remain effective after deployment, proxy or web-server configuration changes.
PASS

HTTP methods are intentionally configured, unnecessary methods are rejected and supported state-changing operations are appropriately protected.

FAIL

An unnecessary or unsafe method remains exposed and creates a material security or configuration weakness.

NOT TESTED

The application's effective method handling could not be adequately determined.

12 / EVIDENCE

Evidence requirements

Endpoint tested
Expected HTTP method set
OPTIONS response where applicable
Tested unsupported methods
HTTP status returned
Evidence of actual unintended behavior if identified
Authentication and authorization test result
Remediation configuration
Post-remediation verification
Final PASS / FAIL determination
Sanitize HTTP evidence

Remove authentication cookies, bearer tokens, API keys, session identifiers and other sensitive values from captured requests and responses before storing or sharing evidence.

13 / CLASSIFICATION

Classification

WebOTG procedure WebOTG-SM-015
OWASP category A02:2025 — Security Misconfiguration
Procedure type HTTP method configuration review
Assessment result PASS / FAIL / NOT TESTED
Finding severity Determine from the exposed method, actual functionality, authentication and authorization controls, exploitability and resulting security impact.
WebOTG classification notice

WebOTG-SM-015 is a WebOTG-defined verification procedure. The identifier is not an OWASP-defined test identifier.

14 / REFERENCES

References

Source Relevance
OWASP Top 10:2025 — A02 Security Misconfiguration category.
OWASP Web Security Testing Guide Web application security testing methodology.
OWASP Application Security Verification Standard Verification requirements relevant to application configuration and access control.
HTTP Semantics Definitions and expected behavior of HTTP request methods and responses.
Application API specification Defines the methods intentionally supported by application resources.

WebOTG should maintain official source URLs, source versions and review dates through its content-management system so references can be updated independently of the procedure template.