Securing a WebDAV Endpoint

WebDAV endpoints tend to arrive in an administrator's life unsecured. Sometimes you inherit one — a departmental server somebody enabled "temporarily," a document system whose DAV interface has been quietly reachable for longer than anyone can remember. Sometimes you are about to create one, because a scanner or a partner or a workflow genuinely needs it. Either way, the same fact applies: a WebDAV endpoint is a web server that accepts writes, and that single property changes everything about how carefully it must be locked down.

This article, part of our WebDAV series, is the full hardening pass, in the order you should run it: transport encryption, authentication, method lockdown, path isolation, execution safety, and logging — finishing with a checklist you can run against any DAV endpoint you are responsible for. Every step works on inherited servers as well as new ones, and none of them requires knowing which product is serving DAV underneath; where configuration syntax appears, it is labeled as an example of a pattern every server can express.

Why WebDAV Changes Your Threat Model

An ordinary web server is a one-way street: the world sends GET, the server sends content. Its worst days involve leaked files or an exploited application. Enable WebDAV and the street runs both directions. The methods described in how WebDAV extends HTTP — PUT, DELETE, MOVE, MKCOL, PROPFIND — give remote clients the ability to write to your disk, rearrange your tree, and enumerate everything in it. Concretely, a badly secured endpoint offers attackers four gifts:

• Free hosting. An open PUT means anyone can store files on your server — pirated content, phishing pages, malware for distribution. Automated scanners probe the internet for exactly this, testing PUT against every web server they find, all day, every day.
• A map of your data. PROPFIND with a Depth header is a structured listing service: names, sizes, and timestamps for entire trees, delivered as tidy XML. What a directory-listing misconfiguration leaks by accident, an unauthenticated PROPFIND leaks by design.
• Deletion and vandalism. DELETE aimed at a collection removes the whole subtree; MOVE can silently rearrange it.
• A path to code execution. If uploads land anywhere the server will execute — a directory where scripts run — then PUT of a script file plus one GET equals an attacker running code on your machine. This is the classic WebDAV kill chain, and step five below exists to break it.

None of this argues against running WebDAV. It argues for running the pass below, because every one of those gifts has a straightforward control.

Step 1: TLS, With No Plaintext Exceptions

Everything else in this article assumes the connection is encrypted, so it comes first. WebDAV's most common authentication scheme, Basic authentication, sends the username and password merely encoded — not encrypted — in every single request. Over plain HTTP, anyone positioned on the network reads credentials at will, and because HTTP is stateless, they get a fresh copy with each request. Basic over HTTP is not "weak"; it is disclosure.

The policy is short: the endpoint answers DAV methods over HTTPS only. Port 80 should either be closed or serve nothing but a redirect to HTTPS — and the redirect must never be the thing that "makes it work," because a client that starts on HTTP has already offered its first request in the clear. Modern TLS versions only, a certificate that clients can validate (from a public authority for internet-facing endpoints, or your internal authority for internal ones), and a periodic external check that the certificate chain is complete and current. Several OS clients help enforce this for you — the Windows WebDAV client refuses Basic authentication over plain HTTP by default — but client mercy is not a security control. If a colleague suggests plain HTTP "because it's only temporary," the answer is the same one you would give for any credentialed service on the network.

Step 2: Authentication, Chosen Deliberately

With TLS in place, choose how users prove who they are. The realistic menu:

• Basic over TLS — username and password inside the encrypted tunnel. Simple, supported by every client ever written, and perfectly respectable once TLS is mandatory. This is the pragmatic default for most endpoints.
• Digest authentication — an older scheme that avoids sending the password itself, at the cost of dated cryptography and fussier client support. It survives mostly as a compatibility option; with TLS mandatory, it offers little over Basic and complicates troubleshooting. Prefer Basic-over-TLS unless a specific client population requires Digest.
• Integrated and negotiated schemes — single sign-on tied to your directory, where the web server participates in your identity infrastructure. Excellent inside an organization; support across the WebDAV client zoo varies, so test the clients you actually have.
• Client certificates — the strongest option: the client proves identity with a certificate during the TLS handshake, before a single DAV method is spoken. Superb for small populations of managed machines or system-to-system flows; a certificate-lifecycle chore at human scale.

Whichever scheme you pick, surround it with account hygiene, because an internet-facing endpoint will be guessed at constantly. Dedicated accounts per person or per system — never one shared "webdav" login, which turns your access log into a mystery novel. Strong passwords, because password guessing over HTTPS looks like ordinary traffic. Lockout or rate limiting on failed attempts. And an expiry review: accounts for departed users and decommissioned scanners have a way of outliving their owners on exactly this kind of server.

Step 3: Method Lockdown

Here is the step most inherited endpoints have never had: trimming the verb set to what the workload actually uses. Start from the truth that most WebDAV populations are asymmetric — many readers, few writers, and often no one at all who legitimately needs PROPPATCH or depth-infinity listings. The principle: every method you do not serve is attack surface you do not carry.

Inventory what each user group does, then enforce it server-side. A read-only consumer needs exactly four methods: GET, HEAD, OPTIONS, PROPFIND. Editors add PUT, MKCOL, MOVE, DELETE, and — if their clients use locking — LOCK and UNLOCK. Almost nobody needs PROPPATCH unless an application explicitly sets custom properties. Here is the pattern expressed in Apache-flavored configuration — the directive names differ on other servers, but every serious web server can express the same rules:

# Illustrative Apache-style configuration for a DAV location
<Location /dav/projects>
    Dav On
    AuthType Basic
    AuthName "Project files"
    AuthUserFile /etc/httpd/conf/dav.passwd

    # everyone must authenticate, even to read
    Require valid-user

    # only named editors may use methods beyond the read-only set
    <LimitExcept GET HEAD OPTIONS PROPFIND>
        Require user editor-svc alex
    </LimitExcept>

    # cap XML request bodies (PROPFIND/PROPPATCH payloads)
    LimitXMLRequestBody 131072
    # cap uploads at 200 MB
    LimitRequestBody 209715200
</Location>

# leave expensive whole-tree listings disabled (Apache default)
DavDepthInfinity Off

Three details in that pattern deserve emphasis. First, authentication applies to reads too — an endpoint that lets the world PROPFIND but only editors PUT is still leaking its entire inventory. Second, size caps: a limit on XML request bodies blunts abusive property requests, and a limit on upload size keeps one client from feeding you a disk-filling file. Third, depth-infinity PROPFIND stays off — a single request that enumerates a whole tree is a denial-of-service invitation and an intelligence gift, and no mainstream mounting client requires it.

Then verify from the outside, with the same probes an attacker would use:

# What does the endpoint admit to supporting?
curl -si -X OPTIONS https://files.example.com/dav/projects/ | grep -iE "^(Allow|DAV):"

# Anonymous PUT must fail with 401
curl -si -X PUT -d "test" https://files.example.com/dav/projects/probe.txt | head -1

# Anonymous listing must fail with 401
curl -si -X PROPFIND -H "Depth: 1" https://files.example.com/dav/projects/ | head -1

Anything other than a 401 on those anonymous probes means step 3 is not finished.

Step 4: Path and Account Isolation

Assume something eventually goes wrong — a leaked password, a misbehaving client — and pre-limit the blast radius.

• Give DAV its own address. A dedicated hostname or subdomain, not a path grafted onto an existing application's site. Separation keeps the application's cookies and sessions out of DAV's scope, lets you firewall and monitor the endpoint independently, and makes retirement possible without touching anything else.
• Give the tree its own storage. The DAV root belongs on a dedicated volume or a quota-limited path, so a runaway upload fills the DAV volume — clients see 507 Insufficient Storage, a WebDAV status invented for exactly this — instead of filling the operating system's disk and taking the whole server down with it.
• Scope each account to its own subtree. The scanner account sees the scans folder; the partner account sees the exchange folder; nobody's credential opens the whole tree. WebDAV inherits whatever path authorization the web server can express, so use it.
• Kill the escape routes. The serving process should follow no symbolic links inside the tree and should run as a low-privilege account with write access to the DAV root and nothing else. Traversal bugs and link tricks are ancient, and the defense is the same as it ever was: the server process must be physically unable to write anywhere interesting.

Step 5: Never Let Uploads Execute

This step gets its own heading because it breaks the most dangerous chain in the threat model. The scenario: your web server executes scripts in some directories — most do, for some language or another — and your DAV tree lives inside one of them. An attacker with write access (or an open PUT you missed) uploads report.php or its cousin in any executable format, then requests it with GET. The server does not return the file; it runs it. That is remote code execution assembled from two perfectly normal features.

The defenses are simple and belong in layers: put the DAV tree in a location where no execution handlers apply, and explicitly disable script execution for that location in the web server configuration anyway (belt and suspenders — configurations drift). If the same tree is also browsed over the web, serve its contents with headers that force download rather than in-place interpretation. And test it the direct way: PUT a harmless script through DAV, request it with GET, and confirm you receive the file's source text rather than its output. Add malware scanning of the upload directory if your policy calls for it — a shared write target reachable from the internet deserves at least the scrutiny your mail attachments get.

Step 6: Logging That Answers Questions

WebDAV's blessing for defenders: every operation is an HTTP request, so your ordinary web access log — method, path, user, status, bytes, source address — is already an audit trail of every read, write, rename, and delete. Make sure it captures the extended methods (a log that only recognizes GET and POST is discarding the interesting rows), keep it per your retention policy, and actually look at it for the handful of patterns that matter on a DAV endpoint:

• Failed-authentication streaks — password guessing, or a stale cached credential hammering the account into lockout (the benign twin; see troubleshooting WebDAV).
• PROPFIND floods from one source — someone enumerating your tree, or a runaway client stuck in a listing loop.
• PUTs of unexpected types or sizes — script extensions where documents should be, or uploads bumping against your size cap.
• A burst of 5xx or 507 responses — the storage or quota conversation you want to have before users do.

The same log is your troubleshooting instrument — the request stream tells you what a misbehaving client is actually doing — so investment here pays twice.

The Hardening Checklist

The whole pass, in checkable form. Run it on every new endpoint and every inherited one; re-run after configuration changes.

WEBDAV ENDPOINT HARDENING CHECKLIST

Transport
[ ] DAV methods answered over HTTPS only; port 80 closed or redirect-only
[ ] Modern TLS versions only; certificate valid and externally verified

Authentication
[ ] Every path requires authentication - reads included
[ ] Basic auth permitted only over TLS
[ ] Dedicated account per user/system; no shared logins
[ ] Lockout or rate limiting on failed attempts; account list reviewed

Methods
[ ] Read-only roles limited to GET / HEAD / OPTIONS / PROPFIND
[ ] Write methods restricted to named editors
[ ] PROPPATCH disabled unless an application needs it
[ ] Depth: infinity PROPFIND disabled
[ ] Upload size and XML body size capped

Isolation
[ ] Dedicated hostname; separate from web applications
[ ] DAV root on dedicated/quota-limited storage (507 tested)
[ ] Each account scoped to its own subtree
[ ] No symlink following; server process runs low-privilege

Execution safety
[ ] No script execution anywhere in the DAV tree
[ ] Verified: PUT a script, GET returns source not output
[ ] Browsable trees served with download-forcing headers

Visibility
[ ] Access log records extended methods, user, status, bytes
[ ] Alerts: auth-failure streaks, PROPFIND floods, odd PUTs
[ ] External OPTIONS probe shows only intended methods
[ ] Endpoint has a named owner and a review date

Sometimes the Right Fix Is a Smaller Door

The final hardening question is the one this checklist cannot answer: does this endpoint need to be WebDAV at all? Inherited DAV servers often exist because, once upon a time, someone needed "a way for people to get files," and DAV was what the server offered that week. If today's actual traffic is humans occasionally uploading and downloading — no mounts, no locking, no properties — then a plain HTTPS transfer portal does the same job through a browser with a fraction of the surface: no extended methods to lock down, no client quirks to support. A file transfer server such as Sysax Multi Server provides exactly that browser-based HTTPS access, alongside SFTP and FTPS for the scripted flows. And if the endpoint's real users are scheduled jobs rather than people, that is SFTP's home ground. Shrinking the protocol to fit the need is the hardening step that removes whole categories of risk at once.

The Pass, Recapped

Securing WebDAV is not exotic; it is web-server discipline applied to a server that accepts writes. TLS with no plaintext path. Deliberate authentication with per-user accounts and lockout. Methods trimmed to each role's actual needs, verified from outside with curl. The tree isolated in address, storage, and privilege. Execution divorced from storage, tested directly. Logs that capture the extended methods and someone who reads them. Run the checklist, and an inherited endpoint stops being a question mark on the network diagram.

For the protocol knowledge underneath these controls, see how WebDAV extends HTTP; for the client behaviors your newly hardened endpoint will meet, mounting WebDAV drives; and for the day something misbehaves anyway, the troubleshooting guide.

Frequently Asked Questions