How to Fix Dangerous HTTP Methods
Use this page when the HTTP Methods Checker shows unnecessary verb exposure on public routes.
What This Means
HTTP method exposure becomes risky when the public edge allows verbs that do not match the route purpose. The right fix is to align allowed methods with real application behavior and make sure proxies, WAFs, and app frameworks enforce the same contract.
| Method | What to verify | Why it matters |
|---|---|---|
| TRACE | Whether it is enabled anywhere public | Usually unnecessary and should stay off. |
| PUT / DELETE | Whether the route truly needs public write behavior | Commonly exposed by mistake on legacy APIs or proxies. |
| OPTIONS | Whether preflight behavior matches the real API contract | Can be misleading or overly broad if not reviewed carefully. |
| WebDAV verbs | Whether uncommon methods are inherited from old defaults | These often indicate stale configuration. |
Common Causes
Patterns worth checking first
- Server defaults: The web server or framework allowed more verbs than the application intended.
- Legacy APIs: Old endpoints still accept methods that no current workflow needs.
- Proxy mismatch: The edge allows verbs that the origin was supposed to restrict.
How To Confirm It Safely
Confirmation steps
- Check which routes and hosts expose the risky methods publicly.
- Separate intentional API behavior from accidental default behavior.
- Review CORS and preflight expectations before narrowing OPTIONS handling.
- Confirm whether the origin and proxy enforce the same method policy.
Fix Workflow
- Map allowed methods by route type. Document which routes are static, public read-only, or authenticated write surfaces.
- Restrict obvious excess first. Disable TRACE or unused write verbs where they clearly do not belong.
- Align edge and origin policy. Make sure proxies, WAFs, and app frameworks enforce the same contract.
- Retest exposure. Re-run the checker and verify the route now exposes only the intended methods.
Implementation Examples
Nginx method restriction example
location / {
limit_except GET POST HEAD {
deny all;
}
}Rollout Risks
Method tightening can break APIs if ownership is unclear
What looks unnecessary may still support a real integration.
- Confirm ownership before blocking write verbs.
- Retest API clients and browser preflight behavior after changes.
Proxy-only fixes can leave the origin inconsistent
If only one layer is corrected, internal drift often returns later.
- Align policy across stack layers.
- Document the intended public verb contract.
Validation Checklist
Post-fix validation
- Obvious excess methods such as TRACE are no longer exposed publicly.
- Routes now allow only the methods they intentionally need.
- Proxy and application behavior align on the final public response.
- The HTTP Methods Checker confirms reduced verb exposure.
FAQ
Should I block OPTIONS everywhere?
Not if the application relies on browser preflight or legitimate API discovery behavior.
- Review real CORS flows first.
- Limit OPTIONS deliberately rather than blindly.
Is public DELETE always wrong?
No, but it should be intentional and protected.
- Confirm authentication and route purpose.
- Remove it where no current workflow depends on it.