The fix, in one snippet
TraceEnable Off # Apache
# nginx does not implement TRACE; a proxy in front mayIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now sends one TRACE / request, a standard HTTP method defined in RFC 9110 section 9.3.8, with no body. A finding requires a 200 response whose Content-Type is message/http or whose body echoes the request line (TRACE / HTTP/1.1) and headers. A 405 or 501 response, or a redirect, passes. If the server sends an Allow header in response to an OPTIONS request, Scan.now reads that as well and reports it. When a CDN such as Cloudflare terminates the connection, it usually answers for the origin, and the report says so. Rated low, because modern browsers forbid scripts from issuing TRACE, which removes the original attack; the finding is mainly about hygiene and about what the echo reveals.
Why it matters
TRACE was designed for debugging: the server returns exactly what it received, so you can see what proxies changed along the way. The security concern, Cross-Site Tracing, dates from 2003: a script on a malicious page issued a TRACE to a site the victim was logged into, and the echoed request revealed the victim's cookies and Authorization header, defeating HttpOnly. Browsers closed that route long ago; the Fetch standard lists TRACE as a forbidden method, so no page script can send it. What remains is minor: the echo can expose headers added by intermediate proxies (internal IPs, load-balancer identifiers) and it confirms the server's exact behaviour to a fingerprinting tool. PCI DSS approved scanning vendors and most vulnerability scanners flag it anyway, so disabling it removes a recurring finding from reports. Method handling in general is covered in the OWASP testing guide linked below and in our vulnerability scan guide.
How to fix it
Apache, globally (the directive is not allowed in .htaccess):
TraceEnable offnginx rejects TRACE with 405 by default and has no directive to enable it; if you see a finding on nginx, the echo is coming from an upstream, so fix it there. To be explicit, or to limit methods generally:
if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) {
return 405;
}IIS, in web.config:
<system.webServer>
<security>
<requestFiltering>
<verbs>
<add verb="TRACE" allowed="false" />
</verbs>
</requestFiltering>
</security>
</system.webServer>Tomcat: allowTrace on the Connector defaults to false; check that it has not been set to true. Express and most application frameworks do not implement TRACE at all. Verify with curl -X TRACE -i https://example.com/ and expect a 405.
Where this fits
HTTP TRACE method enabled is check 10 of 14 that the website vulnerability scanner runs under exposed files and information disclosure, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Exposed .DS_Store file (low), where a macOS .DS_Store file is served from the web root. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
HTTP TRACE method enabled closes one route in. Immediately below it: WordPress version disclosure, where the site runs WordPress and reveals its exact core version through the generator tag, asset query strings, readme.html or the feed, letting attackers match it against known core vulnerabilities; Redirect parameters on the page, where links or forms on the page carry parameters whose names and values suggest a redirect target (next=, return_to=, url=); robots.txt review, where a review of robots.txt.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and HTTPS is available, where the site could not be reached over HTTPS on port 443, or the TLS handshake failed. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: HTTP TRACE method enabled (low severity)
Scanner check id: http-trace-enabledThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
