What Is a WebDAV Server? How It Works, Use Cases, and Security Risks
A WebDAV server lets users access and manage files over HTTP or HTTPS. It supports remote workflows such as document editing, collaboration, and legacy publishing. Now, WebDAV isn’t automatically unsafe. It becomes a risk when exposed methods, weak authentication, broad permissions, or poor logging allow remote file access to exceed business intent. A proper pentest verifies what the service actually allows, not just whether WebDAV exists.
A WebDAV server often appears quietly.
You find it in a scan result, a reverse proxy route, a cloud VM, a legacy publishing workflow, or a log entry nobody expected.
The service looks like normal web traffic, but the risk lies in the file actions it allows.
That’s why external penetration testing must go beyond just “WebDAV detected". A tester must verify authentication, permissions, exposed methods, logging, and practical access paths before the finding means anything.
What Is a WebDAV Server?
A WebDAV server is a web server that supports Web Distributed Authoring and Versioning.
WebDAV extends HTTP so users and applications can manage remote files and collections.
RFC 4918 defines WebDAV as a set of HTTP extensions for managing resource properties, collections, URL namespaces, and locking.
Put simply: WebDAV turns a web server into a remote file workspace.
Instead of only serving pages, the server supports actions such as listing resources, uploading files, creating folders, moving files, copying files, deleting files, and locking files during edits.
That’s useful when the workflow is intentional and controlled. It’s risky when no one owns the service or when the permissions drift.
How WebDAV Extends HTTP
Standard web traffic relies on methods such as GET and POST. WebDAV adds methods designed for file management.
Common WebDAV-related methods include:
- PROPFIND for retrieving properties and listing resources.
- PUT for uploading or replacing content.
- DELETE for removing resources.
- MKCOL for creating collections, often folders.
- MOVE for moving resources.
- COPY for copying resources.
- LOCK and UNLOCK for managing edit locks.
These methods aren’t inherently poor by default. The security question is who can use them, where they apply, what files they touch, and what gets logged.
- Read-only workflows shouldn’t expose broad write, delete, move, or copy actions.
- Publishing workflows shouldn’t expose unrelated directories.
- Private file stores shouldn’t allow anonymous access.
Common WebDAV Use Cases
WebDAV still appears in modern environments because it solves practical file-access problems.
Common use cases include:
- Document collaboration, where users edit shared files through a web-backed workflow.
- Legacy publishing, where older systems push files to a web server or shared repository.
- Remote file access, where users or applications manage files over HTTP or HTTPS.
Microsoft’s IIS documentation describes WebDAV authoring as a way to enable editing over HTTP and HTTPS, with site-level settings that control how the WebDAV module works with properties, locks, and the file system.
That convenience is why WebDAV needs ownership. File-management functionality should never become accidental internet exposure.
When a WebDAV Server Becomes an Attack Surface
A WebDAV server becomes an attack surface when remote file access is broader than the business intended. The main risks are exposed methods, weak authentication, poor permissions, and weak logging.
Exposed Methods
The first question is simple: which methods are enabled?
OWASP’s Web Security Testing Guide recommends identifying which HTTP methods a server supports and verifying the behaviour rather than trusting a single response.
For WebDAV, PUT, DELETE, MKCOL, MOVE, COPY, and PROPFIND deserve direct review. If write access is exposed, PUT can allow file upload or replacement, depending on authentication, permissions, upload paths, and server handling.
Weak Authentication
WebDAV should use strong authentication for protected content and any write functionality.
Apache’s mod_dav documentation says any location where DAV is enabled should be protected by authentication. It also says Basic Authentication isn’t recommended unless it’s used over an SSL-enabled connection.
For exposed WebDAV, authentication isn’t a convenience setting. It’s a core control.
Strong credentials, HTTPS, MFA where supported, rate limiting, and removal of stale accounts should be part of the baseline.
Poor Permissions
Authentication answers, "Who are you?” Permissions answer, “What are you allowed to do?”
Loose permissions can expose more of the file structure than intended. They can also allow users to upload, overwrite, move, or delete files outside their role.
Microsoft’s IIS WebDAV authoring rules documentation says authoring rules can be defined per URI and specify authoring permissions for that URI space.
That’s the practical standard: permissions should match the workflow, path by path.
Weak Logging
A WebDAV server needs useful logs for authentication, method use, file paths, write actions, delete actions, failed attempts, and unusual client behaviour.
Without those logs, your team struggles to answer basic questions: who accessed the files, what changed, what was uploaded, and when the activity started.
What Security Teams Should Check
A useful WebDAV review focuses on behaviour, not banners.
| Area | What to Check | Why It Matters |
| Exposure | Is WebDAV internet-facing, internal, VPN-only, or behind SSO? | Exposure defines the risk level. |
| Methods | Are PROPFIND, PUT, DELETE, MKCOL, MOVE, and COPY enabled? | Methods define what users can do. |
| Authentication | Is login enforced for every protected path? | Anonymous access mustn’t expose private files or write actions. |
| Permissions | Do users have only the rights they need? | Broad read, write, or delete access creates avoidable risk. |
| File Scope | Which directories are mapped into WebDAV? | Misplaced roots expose sensitive files. |
| Logging | Are auth, method, path, write, and delete events logged? | Logs support detection and investigation. |
The recommendation is direct: if WebDAV has no current owner or business need, remove exposure. If it’s required, restrict it, document it, and test it.
Cloud and hybrid setups need the same review. A cloud-hosted WebDAV server still needs method checks, identity review, storage permission checks, and logging validation.
Where WebDAV sits inside broader cloud infrastructure, a cloud security audit should verify that the surrounding identity, network, and storage controls support the intended access model.
What a Port Scan Misses
A port scan tells you that a web service is reachable. It doesn’t prove whether WebDAV creates practical risk.
A useful finding should never stop at “WebDAV detected".
A proper assessment verifies:
- Which WebDAV methods work.
- Which methods require authentication.
- Whether permissions match the business need.
- Which users can read, write, move, copy, and delete.
- Whether uploads are constrained.
- Which file paths are exposed.
- Whether logs capture meaningful evidence.
- Whether unauthorised attempts trigger alerts.
That’s why WebDAV belongs in both external attack surface testing and web application penetration testing. 7ASecurity’s web application testing service includes manual testing, automation where useful, concise reports, a 100% Quality Guarantee, and free fix verification.
A scanner points at the door. A proper pentest checks who has the key, what rooms it opens, and what your team sees when it’s used.
Practical Recommendations for Exposed WebDAV
Use these recommendations as a baseline.
- Remove internet exposure unless there’s a clear need. File-management services deserve stricter scrutiny than simple content delivery.
- Require HTTPS and strong authentication. Don’t use Basic Authentication without TLS. Remove stale accounts and apply MFA where the access path supports it.
- Disable unneeded methods. If users only need read access, write, delete, move, and copy methods shouldn’t be available.
- Apply least privilege. Limit rights by user, group, path, and action. Review permissions after team, vendor, and workflow changes.
- Constrain upload behaviour. Control file types, file size, upload paths, overwrite behaviour, and storage location.
- Log file actions clearly. Prioritise PUT, DELETE, MKCOL, MOVE, COPY, failed authentication, and sensitive path access.
- Retest after changes. WebDAV controls often depend on web server config, application config, file-system permissions, proxy rules, and identity settings.
Need to Know What Your WebDAV Server Actually Exposes?
7ASecurity can test internet-facing services with clear scope, method verification, permission checks, and practical remediation guidance.
Plan Your Scoped Penetration Test
FAQs
Is a WebDAV Server Secure?
A WebDAV server is secure when it’s intentionally deployed, strongly authenticated, tightly permissioned, monitored, and tested. It becomes risky when exposed methods or file access exceed business intent.
Which WebDAV Methods Matter Most for Security?
PROPFIND, PUT, DELETE, MKCOL, MOVE, and COPY deserve close review. These methods affect listing, upload, deletion, folder creation, movement, and copying of resources.
How Do We Disable WebDAV if We Don’t Need It?
For IIS, remove the WebDAV Publishing feature or disable WebDAV at the site or server level. Microsoft’s IIS WebDAV documentation covers site-level authoring settings. For Apache, disable or remove DAV-related modules such as mod_dav and mod_dav_fs where they’re not required.
What Should a WebDAV Finding Include?
A useful finding should include enabled methods, authentication behaviour, permission scope, exposed paths, evidence of read or write access, logging gaps, business impact, and clear remediation steps.
Turn WebDAV Exposure Into a Clear Fix Plan
A WebDAV server isn’t automatically a vulnerability. Unowned exposure, weak authentication, broad permissions, and poor logging create the risk.
7ASecurity can verify what your WebDAV service exposes, show which actions are actually possible, and give your team a clear fix plan.
