high Infrastructure

HTTP Methods

Web servers support multiple HTTP methods, but only a handful — GET, POST, HEAD, and OPTIONS — should typically be accessible on a public-facing site. Leaving TRACE, PUT, or DELETE enabled exposes your server to Cross-Site Tracing attacks, unauthorised file uploads, and resource deletion. These methods are often enabled by default and overlooked during hardening.

What SecurityStatus Checks

TRACE method — sends an actual TRACE request and checks if the server echoes it back (confirms Cross-Site Tracing is possible)
PUT method — checks if file upload to arbitrary paths may be permitted
DELETE method — checks if resource deletion may be permitted without authentication
OPTIONS response — enumerates the full list of methods the server advertises as allowed

Why This Matters

TRACE was designed for diagnostic looping but enables Cross-Site Tracing (XST): an attacker tricks a browser into sending a TRACE request, and the echoed response includes the victim's cookies and authentication headers — even those marked HttpOnly. PUT on web servers was exploited in early WebDAV attacks to upload malicious files directly. DELETE allows attackers to destroy content if no authentication is enforced at the method level.

How to Fix It

1

Disable TRACE in Nginx

Add this to your server or http block: if ($request_method = TRACE) { return 405; } Or restrict to safe methods only: if ($request_method !~ ^(GET|POST|HEAD|OPTIONS)$ ) { return 405; }
2

Disable TRACE in Apache

Add `TraceEnable Off` to your httpd.conf or apache2.conf (not .htaccess — it must be in a server config file). To restrict other methods: <LimitExcept GET POST HEAD OPTIONS> Deny from all </LimitExcept>
3

Block via Cloudflare WAF

Create a custom WAF rule: Field = HTTP method, Operator = is in, Value = TRACE, PUT, DELETE. Set Action to Block. This applies before traffic reaches your server and requires no server config changes.
4

Handle PUT/DELETE for REST APIs

If your application uses PUT/DELETE for REST API endpoints, restrict the method block to public paths only. Allow PUT/DELETE on /api/* paths while blocking them everywhere else. Never allow these methods on static file paths or the web root.
5

Verify the fix

Run `curl -X TRACE https://yourdomain.com -v` from the command line. You should see a 405 Method Not Allowed response. Run `curl -X OPTIONS https://yourdomain.com -i` and check the Allow header — it should only list safe methods.

Frequently Asked Questions

What is Cross-Site Tracing (XST)?

XST is an attack that uses the HTTP TRACE method to bypass the HttpOnly cookie flag. Normally, JavaScript cannot read HttpOnly cookies. But a TRACE request echoes the entire request back — including all cookies — in the response body, which JavaScript can read. Combined with an XSS vulnerability, this lets attackers steal session cookies that were supposed to be script-inaccessible.

Are PUT and DELETE always dangerous?

No — they are fundamental to REST API design. The risk is when they are enabled on paths that do not require authentication, or on static file paths where no authorisation logic exists. Scope restrictions carefully: allow these methods on authenticated API endpoints, block them everywhere else.

Does Cloudflare block TRACE automatically?

Not by default. Cloudflare proxies traffic and passes all HTTP methods through to your origin unless you explicitly block them with a WAF rule. Check your WAF rules and test with curl to confirm.

Why does my server return 200 for TRACE even though I thought I disabled it?

The configuration may be in the wrong context. In Apache, TraceEnable Off must be in the main server config, not .htaccess. In Nginx, the rule must be in the server block, not inside a location block. Test after every config change with a full server reload.

Related Guides

Check Your Domain Now

Run all 38 security checks including HTTP Methods and get your domain's security grade in under 2 minutes.

Scan Your Domain Free