A public .svn folder rebuilds your source the same way a .git one does

The .git folder leak is well-known enough that people check for it now. Subversion has the exact same problem, and almost nobody thinks about it, because they assume SVN is a relic nobody uses anymore. Plenty of older sites, legacy CMS installs, and enterprise apps still deploy from an SVN checkout, and every one of them drops a .svn directory into the deployed tree.

That directory is the same kind of trapdoor as .git. It holds the metadata Subversion uses to track the working copy, and from it a stranger can pull your source back out.

What's in a .svn directory

When you check out a Subversion working copy, SVN creates a .svn folder to track what's there. Modern SVN keeps most of it in a single SQLite database, .svn/wc.db, and older layouts use an entries file plus a text-base of pristine copies.

wc.db lists every file in the working copy, their versions, and the repository URL they came from. The pristine store holds clean copies of the tracked files. Between them, a public .svn folder is enough for an attacker to enumerate your source tree and reconstruct files, the same way git-dumper rebuilds a repo from a leaked .git. There are off-the-shelf tools that do exactly this for SVN. The attacker doesn't need to be clever; they run the tool and read your code.

Why it ends up public

Same deploy accident as .git: the site was deployed by checking out or updating a working copy directly in the web root, instead of exporting a clean copy of the files.

svn checkout and svn update both create and maintain the .svn directory in place. If that working copy is the document root, the .svn folder is served right alongside your pages. The web server doesn't know it's special; it's just a folder with files in it, and it answers requests for them. The reason this outlives SVN's popularity is that the sites still on SVN tend to be the oldest, least-touched ones, deployed years ago by a process nobody revisits. This is the Subversion twin of a public .git folder; if you grasp that one, you already understand this one, and the lesson is the same: deploy the files, not the version-control metadata.

The fix

Deploy with an export, not a working copy, so no .svn metadata ever reaches the server. And block the directory at the web server as a backstop, exactly as you would for .git.

# deployed by checking out in place
cd /var/www/html
svn update
# .svn/ now sits in the web root, served to anyone

If a .svn folder was ever public, treat anything it could expose as exposed: rotate any credentials that lived in the tracked files, since the whole tree was reconstructable. Then switch the deploy to an export-based process so the metadata never lands in the served directory again.

Whether your .svn directory answers a request is checkable from outside by asking for /.svn/wc.db or /.svn/entries and seeing whether the real file comes back, which is the check SurfaceCheckr runs. It requests those paths, confirms the response is the genuine SQLite database or entries file rather than a soft-404, and flags it if so. It reads enough to be sure and stops; it won't pull your whole tree down. That's the same first move an attacker makes when sizing up an older site, and running it on yourself first is how you close the door before they try it.