Back to scan results
Check 44 of 45

Exposed WebDAV / Backup / Deployment Artifacts

We look for files and directories accidentally left in the public web root after a backup, deployment, migration, or legacy FrontPage/WebDAV publishing workflow. A filename or HTTP 200 response is never enough by itself: the response must match an artifact-specific signature.

What this check probes

The scanner makes bounded, read-only GET requests and reads no more than the first 70 KB of any response. It does not upload, extract, enumerate, modify, or delete files.

  • Backup archives: common names such as /backup.zip, /site.zip, /wwwroot.zip, /backup.tar.gz, /backup.7z, /backup.rar, and a hostname-derived ZIP. ZIP, gzip, 7-Zip, RAR, and tar magic bytes must be present before the check fails.
  • Configuration and source copies: /web.config.bak, /web.config.old, /web.config~, /appsettings.json.bak, /appsettings.Production.json, /.env.backup, PHP configuration backups, and common backed-up ASP.NET/PHP entry pages. Their contents must resemble the expected configuration or source format.
  • Deployment files: Kudu/Azure deployment files, GitLab CI, Azure Pipelines, Jenkins, Docker Compose, npm, and NuGet configuration. Confirmed metadata produces a warning; a recognizable literal credential or token fails.
  • Source maps: for a small number of same-origin JavaScript and CSS assets found on the landing page, the scanner checks the corresponding .map path. A valid version-3 source map produces a warning because it can reveal original source and internal filenames.
  • Legacy publishing metadata: FrontPage _vti_pvt password metadata fails when its credential-file structure is confirmed. Public _vti_inf.html publishing metadata produces a warning.
  • Artifact directories: common backup, deployment, release, artifact, WebDAV, and DAV directories fail only when a real directory index also exposes recognizable backup or deployment filenames.

A randomized nonexistent ZIP establishes the target's custom-error or soft-404 baseline. Matching catch-all pages are excluded. Check 42 separately tests dangerous HTTP methods and live WebDAV protocol behaviour; this check covers the files those publishing and deployment workflows can leave behind.

Why this matters for PCI DSS

A forgotten archive can disclose the entire application, customer exports, connection strings, payment integrations, private endpoints, and credentials in one download. Backup configuration files are especially risky because IIS or another web server may serve an unfamiliar extension such as .bak as ordinary static content even though it protects the live filename.

Deployment manifests and source maps are not automatically a compromise, which is why confirmed files without a literal secret are warnings here. They still give an attacker valuable knowledge about build systems, source paths, package registries, infrastructure, and release processes. PCI-facing systems should publish only the files required to run the production application and keep authentication data, source, backups, and operational tooling outside the document root.

How to fix it

Remove the artifact from the web root first. Store backups in a private, access-controlled location that is not mapped by IIS. Adjust the deployment package so CI/CD publishes a clean build output rather than copying the repository or working directory.

For IIS, uninstall WebDAV Publishing if it is not required and block backup/deployment extensions as a second layer:

<system.webServer>
  <security>
    <requestFiltering>
      <fileExtensions>
        <add fileExtension=".bak" allowed="false" />
        <add fileExtension=".old" allowed="false" />
        <add fileExtension=".zip" allowed="false" />
        <add fileExtension=".7z" allowed="false" />
        <add fileExtension=".rar" allowed="false" />
        <add fileExtension=".gz" allowed="false" />
        <add fileExtension=".map" allowed="false" />
      </fileExtensions>
      <hiddenSegments>
        <add segment="_vti_pvt" />
        <add segment="backups" />
        <add segment="artifacts" />
      </hiddenSegments>
    </requestFiltering>
  </security>
</system.webServer>

Apply extension blocking only after confirming the application does not intentionally serve those file types. URL filtering is defence in depth, not a substitute for removing the files.

Clean the deployment pipeline. Exclude source-control folders, CI manifests, local environment files, editor files, source maps, build logs, package credentials, archives, and previous releases from production output. Make the deployment fail if prohibited files are present.

Rotate exposed secrets. If an archive, configuration copy, npm token, NuGet credential, or legacy password file was public, assume it may already have been downloaded. Revoke and replace every credential it contains, then review access and deployment logs.

Return a genuine 404 or 403. After removal, verify each old URL no longer returns the application shell, a cached download, a CDN copy, or an origin response. Purge relevant CDN and proxy caches.

Fixed it? Re-run the scan to confirm.

Run scan again