How to Disable Dangerous HTTP Methods

Before you disable anything, you need a clear picture of what your server actually accepts. Many servers ship with permissive defaults that expose methods you never intentionally enabled.

• Run curl -v -X OPTIONS https://yourdomain.com/ and inspect the Allow response header — it lists every accepted method.
• Try individual methods manually: curl -v -X TRACE https://yourdomain.com/, curl -v -X PUT https://yourdomain.com/test.txt, curl -v -X DELETE https://yourdomain.com/test.txt.
• Check all subdirectories and API endpoints, not just the root — different virtual hosts or application routes may accept different verbs.
• Review your web server's access logs for any historic use of PUT, DELETE, TRACE, CONNECT, or PATCH from unexpected clients.
• Sensagraph automatically probes your endpoints for enabled HTTP methods and flags dangerous ones in the scan report.

Not every HTTP method is inherently malicious, but several are routinely abused when left enabled on public-facing servers.

• TRACE / TRACK: Echoes the client's request back in the response body. Attackers exploit this for Cross-Site Tracing (XST) attacks to steal cookies and authentication headers, even when HttpOnly is set.
• PUT: Allows clients to upload or overwrite files directly on the server. An unauthenticated PUT can let an attacker plant a web shell in seconds.
• DELETE: Allows clients to remove files from the server, leading to data destruction or defacement.
• CONNECT: Instructs the server to establish a TCP tunnel. When abused, it turns your server into an open proxy for attackers.
• PATCH (unprotected): Can modify resources partially; if not protected by authentication and authorisation, it enables unauthorised data manipulation.
• OPTIONS (verbose): Not inherently dangerous, but disclosing the full Allow header in production gives attackers a free map of your attack surface. Consider returning a minimal or empty response.

Apache uses Limit and LimitExcept directives inside <Directory>, <Location>, or .htaccess blocks to control which HTTP methods are permitted.

• Open your main Apache configuration file (typically /etc/apache2/apache2.conf or /etc/httpd/conf/httpd.conf).
• Add a <LimitExcept> directive that explicitly allows only the methods your application needs (usually GET, POST, HEAD) and denies everything else:
  

  <LimitExcept GET POST HEAD>
    Require all denied
  </LimitExcept>

• To block TRACE specifically, add the following line to your global configuration or virtual host block: TraceEnable Off
• If you use .htaccess files, add the same LimitExcept block there for per-directory control.
• Validate your configuration syntax with apachectl configtest before reloading.
• Reload Apache: sudo systemctl reload apache2 (Debian/Ubuntu) or sudo systemctl reload httpd (RHEL/CentOS).

Nginx does not have a direct equivalent of Apache's LimitExcept, but you can achieve the same result with an if block or a map directive inside your server configuration.

• Open your Nginx server block configuration (e.g., /etc/nginx/sites-available/yourdomain.conf).
• Add the following inside the relevant server or location block to return HTTP 405 for any method that is not GET, POST, or HEAD:
  

  if ($request_method !~ ^(GET|POST|HEAD)$) {
    return 405;
  }

• For a more granular approach, use a map block at the http level to set a variable, then check it per location — this avoids nested if statements.
• Ensure the TRACE method is explicitly blocked; Nginx does not process TRACE at the application level by default, but confirm it is not passed upstream to a proxy.
• Test configuration syntax: sudo nginx -t
• Reload Nginx: sudo systemctl reload nginx

Internet Information Services provides Request Filtering — a built-in module that lets you block HTTP verbs at the web server level before requests reach your application code.

• Open IIS Manager, select your site, and double-click Request Filtering.
• Click the HTTP Verbs tab, then Deny Verb and add each dangerous method: TRACE, TRACK, PUT, DELETE, CONNECT, PATCH (if not used).
• Alternatively, edit web.config directly by adding the following inside <system.webServer>:
  

  <security>
    <requestFiltering>
      <verbs>
        <add verb="TRACE" allowed="false" />
        <add verb="TRACK" allowed="false" />
        <add verb="PUT" allowed="false" />
        <add verb="DELETE" allowed="false" />
        <add verb="CONNECT" allowed="false" />
      </verbs>
    </requestFiltering>
  </security>

• Ensure the WebDAV module is disabled if you do not use it — WebDAV re-enables PUT and DELETE automatically.
• Restart the IIS application pool or the site after making changes.

Web server configuration is your first line of defence, but your application framework should also reject unwanted HTTP verbs independently — defence in depth.

• Node.js / Express: Define routes only for the methods you use (e.g., app.get(), app.post()). Add a catch-all middleware that returns 405 for any other method:
  app.use((req, res) => res.status(405).send('Method Not Allowed'));
• Django: Use class-based views with the http_method_names attribute to whitelist only the methods your view handles, or use @require_http_methods(['GET', 'POST']) decorator.
• Spring Boot (Java): Restrict methods at the @RequestMapping level using the method attribute, e.g., @GetMapping, @PostMapping.
• Laravel (PHP): Define routes with explicit method helpers (Route::get(), Route::post()) and avoid Route::any() or Route::match() with broad method lists.
• Rails (Ruby): Use resourceful routing and avoid adding non-standard actions. Configure config.action_dispatch.return_only_media_type_on_content_type and restrict routes in routes.rb.
• Return a proper Allow header with the 405 response listing only the methods your endpoint genuinely supports.

If your architecture includes an API gateway, load balancer, or reverse proxy (NGINX Plus, HAProxy, AWS API Gateway, Cloudflare, etc.), configure method restrictions there as well — these components intercept traffic before it reaches your origin server.

• AWS API Gateway: Only define the HTTP methods you explicitly need in each resource. All other methods will automatically return a 403 or 404.
• Cloudflare WAF: Create a custom WAF rule that blocks requests where the HTTP method is TRACE, PUT, DELETE, or CONNECT unless they match a specific authenticated path.
• HAProxy: Add an ACL in your haproxy.cfg frontend section:
  acl bad_method method TRACE TRACK CONNECT
http-request deny if bad_method
• NGINX as a reverse proxy: Apply the same if ($request_method ...) directive in your proxy configuration, before the proxy_pass directive.
• Ensure that your gateway and your origin server enforce the same method restrictions — inconsistencies can be exploited by bypassing the gateway directly if the origin IP is exposed.

After making configuration changes, systematically verify that dangerous methods are blocked and safe methods still work correctly. A misconfiguration can silently break legitimate functionality.

• Re-run curl -v -X OPTIONS https://yourdomain.com/ and confirm the Allow header no longer lists blocked methods.
• Test each blocked method individually and confirm you receive a 405 Method Not Allowed (or 403 Forbidden) response, not a 200 or 500.
• Test your application's normal user flows (login, form submissions, API calls) to confirm GET and POST requests still work as expected.
• Test all subdomains, staging environments, and API endpoints separately — a restriction on the root domain does not automatically apply to subdomains.
• Use version control for your configuration files so that changes are auditable and reversible.
• Sensagraph can re-scan your site after configuration changes to confirm all previously flagged dangerous methods have been successfully disabled.

Disabling dangerous methods today is not enough — new deployments, framework updates, or infrastructure changes can re-introduce them. Build continuous verification into your workflow.

• Schedule regular automated security scans (at minimum weekly) to detect any re-emergence of dangerous HTTP methods.
• Configure your web server or WAF to alert on any request using a blocked HTTP method — a spike could indicate an active probe or a misconfiguration.
• Include HTTP method auditing in your CI/CD pipeline: run a quick curl -X OPTIONS check as a post-deployment smoke test.
• Review your server and application configurations after every major dependency update, framework upgrade, or infrastructure change.
• Add HTTP method restrictions to your organisation's security baseline documentation and include them in onboarding checklists for new engineers.
• Track your findings over time using a vulnerability management platform to ensure issues are resolved and do not reappear.