ZenovayTools

HTTP Method Checker

Tests which HTTP methods are enabled on a URL (GET, HEAD, POST, PUT, DELETE, PATCH, TRACE). Flags dangerous methods like TRACE (XST) and unnecessary PUT/DELETE. Grade A-F.

How to Use HTTP Method Checker

  1. 1Enter the URL to test for allowed HTTP methods.
  2. 2The tool sends an OPTIONS request and tests key HTTP verbs.
  3. 3Results show allowed/rejected status for each method with risk levels.
  4. 4Review dangerous methods (TRACE, PUT, DELETE) and recommendations.
Zenovay

Track your website performance

Real-time analytics, session replay, heatmaps, and AI insights. 2-minute setup, privacy-first.

Try Zenovay Analytics — Free

Related Tools

Password GeneratorGenerate strong, random passwords with customizable length, characters, and complexity.
Password Strength CheckerCheck how strong your password is. Get an estimated crack time and improvement suggestions.
HMAC GeneratorGenerate HMAC signatures using SHA-256, SHA-384, or SHA-512 with the Web Crypto API.
AES Encryption/DecryptionEncrypt and decrypt text using AES-GCM with PBKDF2 key derivation. Runs entirely in your browser.

Frequently Asked Questions

What HTTP methods are security risks?▾
TRACE is the most dangerous — it enables Cross-Site Tracing (XST) attacks that can steal cookies even when HttpOnly is set, by exploiting the TRACE reflection with a rogue XSS payload. PUT and DELETE are dangerous if unrestricted as they can allow attackers to upload or delete files. CONNECT can be used to create proxy tunnels bypassing firewalls. These methods should be explicitly disabled unless your application specifically requires them.
Why does my server respond to PUT/DELETE but it's not actually exploitable?▾
A 200/204 response to PUT or DELETE doesn't necessarily mean an attacker can overwrite files — authentication, authorization middleware, and application routing may still block unauthorized actions. However, the exposure of these methods indicates that your server is not restricting them at the HTTP level. Best practice is to disable them at the web server/load balancer level unless explicitly needed (e.g., REST APIs). The checker flags them as risks to investigate, not confirmed vulnerabilities.
What is Cross-Site Tracing (XST) and why is TRACE dangerous?▾
XST is an attack where TRACE echoes back everything including the Authorization header and cookies. Combined with a Cross-Site Scripting (XSS) vulnerability, an attacker can use JavaScript to send a TRACE request and read the echoed cookies — bypassing the HttpOnly flag that normally prevents JavaScript from reading cookies. OWASP recommends disabling TRACE on all production servers. In Apache, add "TraceEnable Off". In Nginx, use "if ($request_method = TRACE) { return 405; }".
What is the Allow header and how does it relate to this test?▾
The Allow header in an HTTP response (typically from an OPTIONS request) lists the HTTP methods the server supports for a resource. If an Allow header is returned, this tool uses it as a guide but still sends probing requests to verify actual behavior — some servers advertise fewer methods than they support. If no Allow header is returned, all methods in the curated test set are probed directly.
How should I disable TRACE in common web servers?▾
Apache: Add "TraceEnable off" in httpd.conf or .htaccess. Nginx: Add "if ($request_method = TRACE) { return 405; }" in server block. IIS: Use Request Filtering module to block TRACE verb. Node.js/Express: Add middleware to reject TRACE requests before route handlers. Load balancers (Cloudflare, AWS ALB): Configure custom WAF rules to block TRACE. Most modern CDNs block TRACE automatically.