HTTP TRACE / TRACK Methods Allowed: How to Disable Them on Apache, IIS, nginx and Tomcat

HTTP TRACE / TRACK Methods Allowed means your web server answers TRACE (or Microsoft’s TRACK) requests by echoing the full request back, which scanners flag as a Cross-Site Tracing (XST) exposure. Fix it by setting TraceEnable Off on Apache, denying the TRACE and TRACK verbs in IIS Request Filtering, keeping Tomcat’s allowTrace false, then verifying with curl and rescanning.

What the scanner is actually detecting

This is a remote, unauthenticated check. The scanner sends a TRACE and/or TRACK request to each web port it finds and flags the port when the server answers with a success response that reflects the request. It never reads your configuration files, so every listening web service (80, 443, 8080, 8443, admin consoles, embedded device interfaces) is judged on its own.

Rapid7 InsightVM and Nexpose run an equivalent TRACE check. Microsoft’s IIS support team points out that tools may report TRACK while actually testing TRACE, so do not assume the method named in the title is the one that answered. Read the plugin output, which usually shows the exact request and response.

How serious is it?

Less serious than the Medium rating suggests. Cross-Site Tracing was described in 2003: a malicious page made the victim’s browser send TRACE, and the echoed response exposed cookies, including HttpOnly ones. That attack depended on browsers letting scripts send TRACE. Today the Fetch standard lists CONNECT, TRACE and TRACK as forbidden methods, so modern browsers refuse to send them from script. Tomcat also strips cookie and authorization headers from TRACE responses even when TRACE is enabled.

What remains is information disclosure. TRACE reflects whatever headers reached the server, including headers that a reverse proxy or load balancer added on the way in (internal IP addresses, routing or identity headers). That can help someone map your proxy chain. The Apache httpd documentation is blunt about its own server: “enabling the TRACE method does not expose any security vulnerability in Apache httpd.” Treat this as cheap hardening that removes a recurring audit item, not as an emergency.

How to confirm it on the host

Send the same requests the scanner sends, from a machine outside the server:

curl -i -X TRACE http://host.example.com/
curl -i -X TRACK http://host.example.com/
curl -ik --http1.1 -X TRACE https://host.example.com/
nmap -p 80,443,8080,8443 --script http-trace host.example.com

A vulnerable server returns HTTP/1.1 200 OK, typically with Content-Type: message/http, and the body repeats your request line and headers. A fixed server returns 405 (Apache, nginx, Tomcat), 501, or 404 (IIS Request Filtering). The --http1.1 flag keeps curl on the same protocol most scanners use over TLS.

Then look at the configuration that is actually loaded:

# Apache (RHEL family and Debian family paths)
grep -Rni 'traceenable' /etc/httpd/ /etc/apache2/ 2>/dev/null

# IIS (elevated command prompt)
%windir%system32inetsrvappcmd.exe list config "Default Web Site" -section:system.webServer/security/requestFiltering

# Tomcat
grep -n 'allowTrace' "$CATALINA_BASE/conf/server.xml"

How to fix it

Apache httpd

The default is TraceEnable On. The directive is valid in the main server config and in virtual host context, and it applies to both the core server and mod_proxy. Apache’s docs also note that TRACE cannot be blocked with <Limit> or <LimitExcept>, so use this directive only.

On RHEL, Rocky and AlmaLinux, add this line at the top level of /etc/httpd/conf/httpd.conf (outside any <VirtualHost>):

TraceEnable Off

Debian and Ubuntu already ship TraceEnable Off in /etc/apache2/conf-available/security.conf. If the host is still flagged, make sure that file is enabled and nothing overrides it:

sudo a2enconf security
grep -Rni 'traceenable' /etc/apache2/sites-enabled/

A virtual host that sets TraceEnable On wins for that site. Remove it, or add TraceEnable Off inside each <VirtualHost> if you prefer the setting to be explicit per site. Validate and reload:

sudo apachectl configtest && sudo systemctl reload httpd     # RHEL family
sudo apache2ctl configtest && sudo systemctl reload apache2  # Debian family

Apache has no TRACK implementation of its own. If TRACK still returns 200, Apache is most likely proxying it to a backend that accepts it. Block it in the proxying virtual host with mod_rewrite:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACK$ [NC]
RewriteRule .* - [R=405,L]

IIS

Per Microsoft, TRACK is disabled in IIS 6 and later, but TRACE can be allowed by default. Use Request Filtering: in IIS Manager select the server or site, open Request Filtering, go to the HTTP Verbs tab, click Deny Verb…, enter TRACE, then repeat for TRACK. The same setting in a site’s web.config:

<configuration>
  <system.webServer>
    <security>
      <requestFiltering>
        <verbs>
          <add verb="TRACE" allowed="false" />
          <add verb="TRACK" allowed="false" />
        </verbs>
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

To apply it server wide in applicationHost.config instead, from an elevated prompt:

%windir%system32inetsrvappcmd.exe set config -section:system.webServer/security/requestFiltering /+"verbs.[verb='TRACE',allowed='False']" /commit:apphost
%windir%system32inetsrvappcmd.exe set config -section:system.webServer/security/requestFiltering /+"verbs.[verb='TRACK',allowed='False']" /commit:apphost

If appcmd reports a duplicate collection entry, the verb is already listed; check whether it says allowed="true". Leave allowUnlisted at its default of true. Denied verbs get an HTTP 404 and are logged with substatus 404.6 (Verb Denied), which is expected, not a failure.

nginx

nginx rejects TRACE with 405 in its own request handling before any location or proxy_pass is evaluated, so TRACE never reaches a backend. TRACK is an unknown method to nginx and is passed through to proxied upstreams. If a backend answers it, add this inside each server block:

if ($request_method ~ ^(TRACE|TRACK)$) {
    return 405;
}

sudo nginx -t && sudo systemctl reload nginx

Apache Tomcat

The HTTP connector’s allowTrace attribute defaults to false. If the finding appears on a Tomcat port, look for allowTrace="true" on a <Connector> in $CATALINA_BASE/conf/server.xml, remove it or set it to false, and restart Tomcat. With allowTrace false, Tomcat answers TRACE with 405.

Load balancers, CDNs and WAFs

If the origin is clean but the scan still hits, the 200 is coming from a device in front of it. Fix it on that device, and read how a WAF changes what a web scan actually sees before deciding which result to trust.

How to verify the fix and rescan

1. Rerun the curl commands from a machine outside the server, against every port and hostname listed in the finding, including each name-based virtual host.
2. Test through the same path the scanner uses. If it scans a public VIP, test the VIP, not the backend node.
3. Confirm the response is 405, 501 or (on IIS) 404, and that the body no longer echoes your request.
4. Rescan with the same policy. For Nessus you can limit the rescan to plugin 11213 on the affected hosts.

This finding only exists at runtime, which is why it appears in DAST and network scans but never in static analysis. If your teams are unsure which tool should catch what, see this overview of SAST, DAST and SCA differences.

What can break and how to roll back

Very little. Browsers and ordinary applications do not use TRACE or TRACK. The realistic casualties are manual proxy debugging and the occasional old monitoring probe that uses TRACE as a health check, so check load balancer health monitors before changing a production VIP. On IIS, the risk comes from over-reaching: setting allowUnlisted="false" turns the verbs list into an allow list and blocks every verb you did not list.

Back up each file before editing. To roll back:

• Apache: remove the TraceEnable Off line (or the rewrite block), run configtest and reload.
• IIS: delete the <add verb=...> lines, or run appcmd.exe set config -section:system.webServer/security/requestFiltering /-"verbs.[verb='TRACE']" /commit:apphost.
• nginx: remove the if block, run nginx -t and reload.
• Tomcat: restore the previous server.xml and restart.

Common false positive reasons

• Wrong device. The response came from a load balancer, CDN or WAF, not from the server you changed, or the reverse.
• Wrong service. The flagged port belongs to something else on the host: a Tomcat or Java admin console, a hardware management interface, or an appliance web UI.
• Default virtual host. A scan by IP address lands on the default site, which may not carry the setting you added to a named virtual host.
• Catch-all application. Some frameworks return 200 with a normal page for any method. If the body does not echo your request, the method is not really supported; record the evidence and mark it accordingly.
• Stale results. The report predates the change or reflects a node that was out of the pool during your test.

FAQ

Is disabling TRACE the same as disabling OPTIONS?

No. OPTIONS lists supported methods and is needed for CORS preflight requests. Leave it alone; this finding is only about TRACE and TRACK.

Why does IIS return 404 instead of 405 after the fix?

That is how Request Filtering reports a denied verb. The IIS log shows 404.6, and scanners treat it as fixed because the request is no longer echoed.

Do I need to block TRACK on Apache or nginx?

Only if they proxy requests to a backend that accepts TRACK. Neither server implements TRACK itself.

Can I ignore this finding?

Technically it is low risk, but it is a five minute change that removes a recurring audit item. Fix it rather than documenting an exception.

Tracking this finding across many hosts

This check fires per port and per host, so a large estate can produce hundreds of rows from several scanners. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners and merges duplicates within each scanner. Nessus findings such as plugin 11213 can be re-tested individually after the change, and AI-drafted, host-specific remediation scripts run through SITEY agents on Windows and Linux only after human approval.

Sources

• Tenable: HTTP TRACE / TRACK Methods Allowed (plugin 11213)
• Apache HTTP Server 2.4 documentation: TraceEnable directive
• Microsoft Learn: Request Filtering <verbs> element
• Microsoft IIS Support Blog: HTTP TRACK and TRACE verbs
• Apache Tomcat 10.1: HTTP Connector configuration (allowTrace)