HTTP Methods Checker

Free HTTP Methods Checker - Test HTTP Verbs & Find Security Vulnerabilities

Our free HTTP Methods Checker tests which HTTP request methods (verbs) are enabled on your web server to identify critical security vulnerabilities. The tool tests 9 common HTTP methods including safe methods (GET, POST, HEAD, OPTIONS) and dangerous methods (PUT, DELETE, PATCH, TRACE, CONNECT), showing which methods are allowed or blocked with specific HTTP status codes. Get instant security assessment (Critical, High, Medium, Safe) showing dangerous methods like PUT/DELETE that allow file manipulation, TRACE method vulnerable to XST attacks, CONNECT method proxy abuse risk, and detailed recommendations for each finding. Essential for web server security audits, preventing unauthorized file uploads and deletions, blocking Cross-Site Tracing (XST) attacks, compliance with PCI-DSS and security standards, and hardening Apache, Nginx, and IIS servers. Includes configuration examples for .htaccess, httpd.conf, nginx.conf, and web.config to properly restrict HTTP methods to only those needed (typically GET, POST, HEAD).

What Are HTTP Methods?

HTTP methods (also called HTTP verbs) are the actions that clients can request a web server to perform on resources through the HTTP protocol. Each HTTP request includes a method that tells the server what operation to execute: retrieving data, submitting forms, uploading files, deleting content, or querying server capabilities. Standard HTTP methods defined in RFC specifications: GET requests data from server without modifying anything (idempotent and safe), POST submits data for processing like form submissions or API calls, HEAD retrieves only response headers without body (like GET but faster), PUT uploads or replaces entire resource at specific URL, DELETE removes specified resource from server, PATCH applies partial modifications to resource, OPTIONS queries which methods are supported for resource (used in CORS preflight), TRACE echoes received request for debugging (dangerous for XSS), CONNECT establishes tunnel to server for proxying (often for HTTPS through proxy). Safe vs unsafe methods: Safe methods like GET and HEAD don't modify server state and can be cached, Unsafe methods like POST PUT DELETE modify server state and aren't idempotent, Idempotent methods produce same result when repeated (GET PUT DELETE but not POST). In typical website operation only GET and POST are needed: GET for viewing pages loading resources browsing content, POST for form submissions login authentication data creation, HEAD occasionally used by crawlers and monitoring tools, OPTIONS required for CORS in modern web applications with JavaScript. The dangerous methods PUT DELETE PATCH should be disabled unless: Building REST API that requires full CRUD operations, Implementing WebDAV for file management over HTTP, Developing specialized application with legitimate need, Even then these methods must be restricted to authenticated authorized users only. TRACE method should always be disabled: Vulnerable to Cross-Site Tracing (XST) attacks, Can bypass HttpOnly cookie protection allowing XSS to steal cookies, Servers echo request allowing attackers to see headers credentials, No legitimate use case in modern web applications, PCI-DSS compliance requires TRACE disabled. CONNECT method abuse risks: Can turn your server into open proxy for attackers, Used to tunnel connections for illegal activity, May bypass firewall rules and access controls, Should only be allowed on dedicated proxy servers. Testing HTTP methods reveals server configuration security posture: Properly hardened servers only allow GET POST HEAD OPTIONS, Misconfigured servers may allow PUT DELETE enabling file manipulation, Old or default configurations often leave TRACE enabled, Our tool tests each method and shows which are allowed versus blocked.

Why Dangerous HTTP Methods Are Security Risks

Allowing unnecessary HTTP methods on your web server creates serious security vulnerabilities that attackers can exploit.

• PUT Method - File Upload Vulnerability (Critical): PUT allows uploading arbitrary files to server at specified paths, attackers can upload malicious scripts PHP shells backdoors, uploaded web shells give complete server control, can replace legitimate files with malicious versions, often no authentication or authorization checking, WebDAV enables PUT but frequently misconfigured, vulnerable servers accept PUT to any writable directory, example attack: PUT /uploads/shell.php uploads backdoor then access via GET, file permissions often allow script execution after upload, can overwrite configuration files or application code, PCI-DSS prohibits PUT unless specifically needed and secured
• DELETE Method - Resource Destruction (Critical): DELETE removes files and resources from server, attackers can delete website files databases backups, no confirmation or authentication in basic implementation, can make entire site unavailable (denial of service), deletion may be permanent without backups, logs and evidence can be removed hiding attacks, often cascades deleting related resources, example: DELETE /index.html removes homepage, DELETE /uploads/ may recursively delete directory, authentication bypass allows unauthorized deletions, should require multi-factor authentication for critical resources
• TRACE Method - XST Vulnerability (High): TRACE echoes HTTP request back to client including headers, vulnerable to Cross-Site Tracing (XST) attacks, bypasses HttpOnly cookie protection via XSS, attacker uses XMLHttpRequest with TRACE to steal cookies, session tokens in headers exposed in response, enables credential theft and session hijacking, OWASP identifies XST as security weakness, modern browsers block TRACE but server must disable too, example: fetch(url, {method: 'TRACE'}) reveals Authorization header, PCI-DSS requirement 6.5.10 requires TRACE disabled, no legitimate use for TRACE in production systems
• CONNECT Method - Proxy Abuse (Critical): CONNECT establishes tunnel through server to another host, allows using your server as proxy for malicious traffic, attackers hide origin by routing through your server, can access internal network from external position, used for illegal activity spam botnet command and control, generates massive traffic consuming bandwidth, your IP gets blacklisted for abuse you didn't commit, legal liability for illegal content proxied through server, example: CONNECT internal.server:22 tunnels SSH through web server, should only be on dedicated authenticated proxy servers
• PATCH Method - Partial Updates (High): PATCH modifies resources with partial updates, less common than PUT but similar risks, can corrupt data with malicious partial changes, JSON patch operations can target sensitive fields, authentication often not properly implemented, example: PATCH /users/admin {"role": "admin"} elevates privileges, PATCH /config/database.json modifies credentials, requires same security as PUT but often overlooked, validate all PATCH operations against authorization
• OPTIONS Method - Information Disclosure (Low): OPTIONS reveals which methods are supported, attackers use OPTIONS to identify vulnerable configurations, shows exact methods allowed before attempting attack, CORS preflight uses OPTIONS revealing cross-origin policy, Allow header lists all available methods, example: OPTIONS / returns Allow: GET,POST,PUT,DELETE, information gathering during reconnaissance phase, disabling OPTIONS doesn't prevent testing other methods, but removes convenient roadmap for attackers
• Verb Tampering Attacks: Attackers change HTTP method to bypass security, application checks POST but attacker uses GET or PUT, method-based authentication bypass vulnerabilities, framework routing may handle methods inconsistently, example: POST /admin requires auth but PUT /admin doesn't, parameter pollution via different methods, test authorization for every method not just common ones, web application firewall must check all methods
• Method Confusion in Proxies/Load Balancers: Proxy translates methods differently than application expects, load balancer allows method backend application doesn't, inconsistent method handling across infrastructure layers, caching proxy caches unsafe methods by mistake, example: proxy allows OPTIONS but backend expects it blocked, security rules on load balancer bypass app-level checks, defense-in-depth requires blocking at all layers
• Framework Default Configurations: Many frameworks enable all methods by default, developers unaware of security implications, REST frameworks auto-enable CRUD methods, WebDAV modules activate PUT DELETE automatically, tutorial code copied without security review, insecure defaults in Apache Nginx IIS, example: Apache with mod_dav enables PUT DELETE, Laravel routes respond to all methods unless restricted, must explicitly whitelist safe methods only

How to Use the HTTP Methods Checker

Testing your server's HTTP method configuration identifies security weaknesses before attackers find them.

• Enter website URL: Input your website URL in the form field, tool automatically adds https:// if not provided, tests against the exact URL specified, works with any public web server, tests from external perspective like attacker would, only test servers you own or have permission to audit
• Click Check HTTP Methods: Tool sends request with each HTTP method, tests 9 common methods (GET POST HEAD OPTIONS PUT DELETE PATCH TRACE CONNECT), uses cURL to send custom HTTP verb, measures response time for each method, determines allowed vs disallowed based on HTTP status codes, entire scan completes in under 30 seconds
• View overall risk assessment: Large visual indicator shows overall security status, Critical Risk if PUT DELETE or TRACE allowed, High Risk if PATCH or CONNECT enabled, Medium Risk if only low-risk methods exposed, Safe if only GET POST HEAD allowed, color-coded for immediate understanding (red critical, green safe)
• Check allowed methods list: Each allowed method shown with details, displays HTTP status code (200=success, 405=not allowed), shows response time measurement, indicates risk level (critical, high, low, safe), explains what each method does, provides specific recommendation, dangerous methods highlighted with warnings
• Review disallowed methods: Methods properly blocked listed separately, confirms server blocking dangerous methods, validates security configuration working, shows HTTP 405 or 501 responses, collapsible section to reduce clutter, helps verify hardening changes took effect
• Read OPTIONS response: If OPTIONS method allowed shows Allow header, server reports which methods it supports, compare OPTIONS response to actual test results, some servers lie in OPTIONS but allow methods anyway, useful for understanding server intent vs reality
• Implement security recommendations: Specific configuration examples provided, Apache .htaccess and httpd.conf snippets, Nginx configuration for blocking methods, IIS web.config security rules, explains which methods to allow/block, shows how to test configuration changes, guidance on WebDAV and REST API security
• Copy or download report: Full report includes all tested methods, shows allowed and blocked methods with details, contains security recommendations, suitable for compliance documentation, track method exposure over time, share with security team for remediation

How to Disable Dangerous HTTP Methods

Properly securing HTTP methods requires configuration changes at the web server level to block unnecessary verbs.

• Apache .htaccess Configuration: Create or edit .htaccess file in web root, use LimitExcept directive to allow only safe methods, <LimitExcept GET POST HEAD> Order Allow,Deny Deny from all </LimitExcept>, this blocks all methods except GET POST HEAD, applies to current directory and subdirectories, test thoroughly before deploying to production, works without restarting Apache (immediate effect), can restrict further for specific directories, more flexible than server-wide config but less performant
• Apache httpd.conf Global Configuration: Edit main Apache config file /etc/apache2/apache2.conf or /etc/httpd/conf/httpd.conf, use Directory directive for web root, <Directory /var/www/html> <LimitExcept GET POST HEAD> Deny from all </LimitExcept> </Directory>, applies server-wide to all virtualhosts if in main config, requires Apache restart: systemctl restart apache2, more performant than .htaccess (no per-directory parsing), cannot be overridden by .htaccess if AllowOverride disabled, better for production environments
• Nginx Configuration: Edit nginx.conf or site-specific config in /etc/nginx/sites-available/, add conditional check in server or location block, if ( !~ ^(GET|POST|HEAD)$) { return 444; }, return 444 closes connection without response, can use 405 to return Method Not Allowed instead, reload Nginx: systemctl reload nginx, test configuration first: nginx -t, more efficient than Apache method checking, can apply different rules per location
• IIS web.config: Add to web.config in application root, <system.webServer> <security> <requestFiltering> <verbs allowUnlisted="false"> <add verb="GET" allowed="true" /> <add verb="POST" allowed="true" /> <add verb="HEAD" allowed="true" /> </verbs> </requestFiltering> </security> </system.webServer>, allowUnlisted=false blocks all methods not explicitly listed, IIS automatically applies changes (no restart), can configure via IIS Manager GUI, applies to entire application and subdirectories
• Disable TRACE Specifically: Apache: TraceEnable Off in httpd.conf or apache2.conf, Nginx: merge_slashes off; (helps prevent TRACE), IIS: typically disabled by default in modern versions, verify TRACE blocked: curl -X TRACE https://yoursite.com, should return 405 Method Not Allowed or 501 Not Implemented, critical for PCI-DSS compliance requirement 6.5.10
• WebDAV Security if Needed: If using WebDAV for file management, enable mod_dav carefully: <Directory /webdav> Dav On Require valid-user </Directory>, require authentication for all WebDAV operations, use Digest or OAuth authentication not Basic, restrict by IP address if possible, log all WebDAV operations, regularly audit who has access, consider alternatives like SFTP or rsync, WebDAV notorious for security issues when misconfigured
• REST API Method Restrictions: For REST APIs allow PUT DELETE only with authentication, use API-specific routes like /api/* for CRUD methods, block PUT DELETE on static content and public pages, implement authorization checks for every method, validate request origin via CORS headers, rate limit PUT DELETE operations, log all state-changing requests, example: location /api/ { limit_except GET POST PUT DELETE { deny all; } auth_basic "API"; }, separate API endpoints from public website
• ModSecurity WAF Rules: Web Application Firewall can block methods, ModSecurity rule: SecRule REQUEST_METHOD "^(?:PUT|DELETE|CONNECT|OPTIONS|TRACE)$" "phase:1,deny,status:405", blocks dangerous methods before reaching application, provides logging and alerting on attempts, easier to manage than server config in some cases, defense-in-depth adds redundancy, can temporarily block without server restart
• Cloud WAF Solutions: AWS WAF, Cloudflare, Akamai can restrict methods, configure via rule sets or managed policies, blocks methods at edge before reaching server, provides DDoS protection simultaneously, logging and analytics on blocked methods, easier for non-technical administrators, may have additional cost, example: Cloudflare firewall rule for HTTP methods
• Test Configuration Changes: After applying changes test each method, use our tool or curl to verify, curl -X PUT https://yoursite.com/test should return 405, verify GET POST still work normally, check application functionality not broken, test with authentication and without, review logs for blocked method attempts, use penetration testing tools like Burp Suite, schedule regular retesting after updates
• Framework-Level Restrictions: Express.js: app.use((req, res, next) => { if (!['GET','POST'].includes(req.method)) return res.status(405).end(); next(); }), Laravel: Route::match(['get', 'post'], '/path', 'Controller@method'), Django: @require_http_methods(["GET", "POST"]), ASP.NET: [AcceptVerbs("GET", "POST")], framework restrictions provide redundancy even if server misconfigured, validate at application layer for defense-in-depth

Pro Tip

The most secure configuration is to explicitly whitelist only the HTTP methods your application actually needs (typically just GET, POST, and HEAD for standard websites) while blocking all others by default using the principle of deny-by-default. Never assume methods are blocked just because you're not using them - many web servers enable PUT, DELETE, and TRACE by default especially with certain modules like mod_dav (Apache WebDAV), so always explicitly configure method restrictions. Implement method security at multiple layers for defense-in-depth: configure web server (Apache/Nginx/IIS) as first line of defense using LimitExcept or request_method conditionals, add .htaccess rules for per-directory granularity, implement Web Application Firewall rules (ModSecurity, cloud WAF) for centralized blocking with logging, validate methods in application code before processing requests, use framework-level decorators or middleware to enforce allowed methods, combine all layers so even if one fails others still protect. Always disable TRACE method completely as it has zero legitimate use cases in production environments and creates XST vulnerability: Apache use TraceEnable Off in httpd.conf, Nginx block with if ( = TRACE) { return 405; }, IIS should be disabled by default in modern versions but verify, test with curl -X TRACE to confirm blocking, TRACE enables Cross-Site Tracing bypassing HttpOnly cookie protection. For WebDAV and file sharing if you must use PUT and DELETE: create separate /webdav/ directory with Dav On, require authentication with Require valid-user, use strong Digest or OAuth authentication never Basic, restrict by IP address to known administrators only, log every WebDAV operation for audit trail, regularly review who has WebDAV access, consider SFTP or AWS S3 as more secure alternatives, limit upload file types and sizes, scan uploaded files for malware. REST API security when PUT/DELETE needed: separate API routes from public website (api.example.com or /api/ path), require OAuth or API key authentication for all methods, implement rate limiting on state-changing operations, validate user authorization not just authentication (can user modify this resource?), log all PUT/DELETE with user identity and timestamp, version your API and deprecate insecure versions, use HTTPS only with TLS 1.2+ for API endpoints, implement CORS carefully restricting allowed origins, never allow method override via X-HTTP-Method-Override without authentication. Common mistakes to avoid: assuming TRACE is disabled by default (often isn't), enabling WebDAV for one directory but it applies globally, using OPTIONS to check what's allowed instead of actual testing (servers can lie), relying on application code validation without server-level blocking, forgetting that PATCH is similar to PUT in security implications, not testing after configuration changes (broken config worse than none), allowing all methods for /api/ including public endpoints, trusting load balancer to block methods without backend protection. Test your configuration regularly: scan monthly with our HTTP Methods Checker tool, verify after software updates especially web server upgrades, check when adding new modules or frameworks, automated security scanning in CI/CD pipeline, penetration testing should include method testing, use tools like Burp Suite, OWASP ZAP, Nikto to verify blocking, monitor logs for 405 errors indicating blocked method attempts, alert on successful PUT/DELETE to non-API endpoints. Remember that security is layered - even with methods properly restricted: validate all inputs regardless of HTTP method, implement proper authentication and authorization, use CSRF tokens for state-changing operations, audit file uploads for malware and size limits, keep web server and application frameworks updated, follow principle of least privilege for all operations, monitor and log all suspicious activities for incident response.

FAQ

Related tools

Pro tip: pair this tool with Security Header Strength Checker and Exposed Admin Path Detector for a faster SEO workflow.

• Security Header Strength Checker — Grade security headers with detailed scoring, letter grades (A+ to F), and actionable recommendations.
• Exposed Admin Path Detector — Detect common admin URLs that may expose login panels or sensitive areas.
• Robots.txt Security Analyzer — Analyze robots.txt to detect exposed admin, login, and sensitive paths.
• Google Malware Checker — Check if site has malware.
• Security Headers Checker — Check if website implements essential security headers like CSP, HSTS, X-Frame-Options.