Serving websites from svn checkout considered harmful

22 April 2008

Serving from a working copy

A simple way to update sites is to serve them from Subversion working copies. Checkout the code on the server, develop and commit changes, then svn update the server when you’re ready to release.

Security concerns

There’s a potential security problem with this. Subversion keeps track of meta-data and original versions of files by storing them in .svn directories in the working copy. If your web server allows requests that include these .svn directories, anything within them could be served to whoever requests it.

Requests would look like:

The first one would reveal some meta-data about your project, such as file paths, repository urls and usernames.

The second one may be interpreted as a PHP script, in which case there’s little risk. Or it may return the PHP source file, which is a much bigger risk.

The third one (assumed to be a Django project) should never happen. The request can only be for files within the web server’s document root. Code itself doesn’t need to be there, only media files do.


Instead of serving sites from a working copy, you can use svn export to get a “clean” copy of the site which does not include .svn directories. If you svn export from the repository, you must export the complete site, rather than just update the changed files, which could be a lot more data.

However, you can svn export from a working copy on the server. It’s still a complete export, but you don’t have to trouble the repository, so it’s typically much quicker.

An alternative is to update a working copy which is stored on the server, but not in the web document root, then use rsync or some file copying to update the “clean” copy in the web document root. In this case, only changed files are affected.

Protection through web server config

If you do serve from working copies, you should configure the web server to block all requests which include .svn in the url. Here’s how to do it for some popular web servers:


<LocationMatch ".*\.svn.*">
    Order allow,deny
    Deny from all


$HTTP["url"] =~ ".*\.svn.*" {
  url.access-deny = ("")


Using the location directive which must appear in the context of server.

server {
location ~ \.svn { deny all; }
Filed under: Hosting,Security — Scott @ 9:48 pm


  1. Wow! Thanks for opening my eyes on this.

    I’m so surprised that this isn’t a well-known issue for web developers using subversion.

    I just sent your article out to a bunch of colleagues.
    Thanks again,

    Comment by Jonathan — 26 October 2008 @ 3:09 pm

  2. I use darcs rather than svn for my webpage, and noticed the darcs equivalent to this a few months ago. It’s a problem with most VC systems.

    Comment by Jason — 19 December 2008 @ 2:27 am

  3. i’ve been messing around with my lighttpd regex patterns trying to solve this issue –

    $HTTP["url"] =~ ".*\.svn.*" {
    url.access-deny = ("")

    still allows me to access/download the /.svn/entries and /.svn/format files, but protects the directory. Anyone else have similar results?

    p.s. – i’m actually planning on using:

    url.redirect-code = 404

    instead of

    #url.access-deny = ("")

    I believe this is a better strategy – that way you’re denying that the files are even there. The equivalent in Apache is:

    RedirectMatch 404 /\\.svn(/|$)

    (the apache directive protects the entries and format files)

    Any help is appreciated!!

    Comment by rtw — 12 March 2009 @ 8:27 pm

  4. stupid russian idiots published this news 1 year after you…))

    Comment by Alex — 18 January 2010 @ 1:07 am

  5. […] почитать по теме можно здесь:; Запись опубликована в рубрике Новости. Добавьте в […]

    Pingback by SVN уязвимость года. Подвержены крупнейшие веб-проекты Интернета — 1 October 2010 @ 7:59 am

  6. Yeah, loves to copy content from other websites; a disgrace. But then again, almost all of runet is a rip off, which is sad.

    Anyway, thanks for the article! But I wonder, why the developers never care to test that themselves? That is troubling.

    I was always using export for deployment but it’s kind of a headache because you end up deleting and overwriting files and restarting the services. So, I found your article and I find serving 404 a reasonable alternative.

    Comment by Dmitry — 15 February 2011 @ 9:28 pm

  7. […] Reason :: […]

    Pingback by Cara Mengamankan SVN live site pada WHM/Cpanel ( to be revised ) | Indonesian Developer — 15 September 2012 @ 9:37 am

RSS feed for comments on this post.

Leave a comment