Back to scan results
What this check probes
The scanner sends OPTIONS and read-only, depth-one PROPFIND requests to the HTTP and HTTPS root plus a bounded set of common WebDAV paths. It reviews the Allow, Public, DAV, and MS-Author-Via headers and validates WebDAV 207 Multi-Status XML rather than trusting a header by itself.
- Failure: an unauthenticated depth-one
PROPFIND returns a valid WebDAV collection containing multiple resource entries. This confirms anonymous collection enumeration.
- Warning: WebDAV is advertised or accepts an anonymous
PROPFIND, but no collection disclosure or write access is confirmed.
- Pass: WebDAV is absent, or an advertised endpoint rejects anonymous
PROPFIND with HTTP 401/403.
PUT, DELETE, PATCH, MOVE, COPY, MKCOL, and locking verbs can be legitimate behind authentication. The scanner records relevant advertisement but does not fail a normal API merely for naming those methods. TRACE acceptance remains covered by check 4.
The scanner never sends PUT, DELETE, PATCH, PROPPATCH, MKCOL, MOVE, COPY, LOCK, or UNLOCK. It does not create a test file or collection and therefore has nothing to clean up afterward.
Why this matters for PCI DSS
Unnecessary public WebDAV expands the attack surface and can disclose filenames, backup artifacts, configuration material, or application structure. If write-capable methods are also usable without strong authorization, an attacker may be able to store active content, alter files, or abuse the host as public storage.
For PCI readiness, externally reachable services and protocols should have a documented business purpose, secure configuration, least-privilege access, current patching, strong authentication where required, and logging. Disable WebDAV when it is not needed; when it is needed, isolate it from the public payment application and restrict both identities and methods.
How to fix it
On IIS, uninstall the WebDAV Publishing role service if the server does not use it. For an individual ASP.NET Framework 4.7.2/4.8 site, remove the WebDAV module and handler, then allow only the verbs the application actually uses:
<system.webServer>
<modules>
<remove name="WebDAVModule" />
</modules>
<handlers>
<remove name="WebDAV" />
</handlers>
<security>
<requestFiltering>
<verbs allowUnlisted="false">
<add verb="GET" allowed="true" />
<add verb="HEAD" allowed="true" />
<add verb="POST" allowed="true" />
<add verb="OPTIONS" allowed="true" />
</verbs>
</requestFiltering>
</security>
</system.webServer>
Add PUT, DELETE, or PATCH only when a real API endpoint requires them and enforces authentication, authorization, CSRF/CORS policy where applicable, object-level access controls, and request limits. Test the complete application before deploying a server-wide verb allowlist.
On Apache, disable unused DAV modules and turn DAV off for the public document root:
Dav Off
<Directory "/var/www/html">
<LimitExcept GET HEAD POST OPTIONS>
Require all denied
</LimitExcept>
</Directory>
On nginx, remove unused DAV modules/directives and restrict methods in the applicable location:
location / {
limit_except GET HEAD POST OPTIONS {
deny all;
}
}
If WebDAV is genuinely required, place it on a dedicated path or host, require HTTPS and strong authentication, authorize access per collection, disable script execution and public serving in writable storage, restrict methods to the minimum required, enforce upload type and size controls, and log collection and write operations. Keep payment-system files and backups outside every DAV-accessible directory.