HTTP Methods Checker Guide
Use this guide to understand what the HTTP Methods Checker is validating, which verbs are truly needed on the public edge, and how to restrict unnecessary methods without breaking APIs or preflights.
Overview
The useful question is not whether a server responds to many HTTP verbs. It is whether the exposed methods match the real purpose of the route. Unnecessary methods create operational noise and sometimes direct risk on legacy or misconfigured stacks.
Methods that deserve review first
- TRACE: Almost never needed on a public application and usually disabled outright.
- PUT or DELETE: Fine on intentional authenticated APIs, risky on public or forgotten endpoints.
- OPTIONS: Often required for CORS, but it should not imply support for methods you do not actually allow.
Common Methods and Expected Use
| Method | Typical use | When it becomes risky |
|---|---|---|
| GET | Read-only content or retrieval | Sensitive data still needs auth and cache review. |
| POST | Form submission or create actions | Weak auth or validation turns expected POST into abuse surface. |
| PUT/PATCH | Authenticated update flows | Unexpected exposure on public paths reveals management behavior unintentionally. |
| DELETE | Authenticated delete flows | Should not be reachable on routes that were never meant to manage state publicly. |
Practical Restriction Examples
location /api/account {
limit_except GET POST {
deny all;
}
}<Location "/api/account">
<LimitExcept GET POST>
Require all denied
</LimitExcept>
</Location>Recommended Remediation Flow
- Map routes by purpose Separate marketing pages, authenticated app routes, APIs, uploads, and health endpoints first.
- Disable methods that are not intentionally supported Start with TRACE and other obviously unused verbs.
- Review OPTIONS alongside CORS policy A safer methods policy should still preserve the preflight behavior the real frontend needs.
- Retest application and integration flows Method changes often break background jobs or admin tooling if inventory was incomplete.
Troubleshooting Common Issues
CORS preflight breaks after method tightening
OPTIONS may still be required even if only GET and POST are used by the application.
- Confirm what the browser is actually requesting during preflight.
- Keep OPTIONS behavior aligned with the real allowed methods and headers.
- Review CORS and method rules together, not as separate fixes.
API clients fail after blocking PUT or DELETE
This usually means the route really did depend on those verbs and the inventory was incomplete.
- Review API documentation and real client traffic before finalizing the restriction.
- Block the verb only on routes where it was truly unneeded.
- Consider stronger auth instead of blanket removal where the method is legitimate.
Validation Checklist
Post-fix validation
- Confirm public pages expose only the methods they intentionally support.
- Retest APIs, background jobs, admin actions, and browser preflights after changing method rules.
- Verify TRACE or other disallowed verbs now return the expected deny response.
- Run the HTTP Methods Checker again and compare the public method map to the intended route inventory.
FAQ
Should every site block PUT and DELETE at the edge?
Not always. Many real APIs need them. The requirement is intentional exposure, not blanket removal.
- Keep them where the application genuinely depends on them.
- Require strong auth and route scoping on state-changing endpoints.
- Block them on public or legacy paths where they serve no real purpose.
Is OPTIONS always harmless?
No. It is often necessary, but it still needs to reflect the real behavior you intend to support.
- Review it alongside CORS policy.
- Avoid advertising methods the backend does not actually mean to allow.
- Retest from the browser path, not only with raw curl calls.