highSeverity: highRisk ratingHow usable this gap is to an attacker. Severity sets the posture penalty: critical −40, high −20, medium −10, low −4, info −1. Higher severity means fix it sooner.Deploy config / web serverWhere it livesImplementationThis fix is applied in: Deploy config / web server. That's the surface you'll edit, DNS, response headers, or a static file.~10 minTime to fixEffortRoughly 10 minutes of hands-on work, propagation aside. Most of these are copy-paste.+20 posture+20 postureScore impactPoints this fix recovers in the ApeCyber posture score (0–100). Posture = 100 minus the severity penalty of every open finding; clearing this finding adds these points back.

Exposed .svn: keep your source history off the public web

Blocking /.svn and deploying build artifacts stops anyone from reconstructing your source, secrets included.

The threat

The scanner requested /.svn/wc.db and got a file back. That is Subversion’s working-copy database (a SQLite file), and it should never be reachable from the internet. Its presence means a Subversion working copy, not a clean build, was deployed straight into your web root, so the whole .svn metadata folder shipped along with it.

That folder is enough to rebuild your source. Modern Subversion keeps the original contents of every tracked file in .svn/pristine/, indexed by wc.db, so someone can walk the database and pull down your code file by file: comments, config, and any credential ever committed alongside it. It is the same exposure as an open .git directory, just a different tool.

The exact fix

Two steps, in order. First contain, then stop serving.

1. Rotate anything secret that ever lived in the repo. If a password, API key, token, or connection string was ever committed (even in an old revision you later deleted), treat it as public now and rotate it at the source. Subversion keeps history, so “we removed it later” does not help you here.

2. Stop serving the working copy. The real fix is to deploy build output, not a checkout. Export a clean tree or publish your build artifacts, so there is no .svn folder in the web root at all:

# instead of copying a working copy, export a clean tree
svn export https://svn.internal/yourproject/trunk ./release
# then deploy ./release (no .svn metadata inside)

Block the path at the server too, as a backstop, so any stray .svn is unreachable.

nginx:

location ~ /\.svn/ {
    deny all;
    return 404;
}

Apache (.htaccess or vhost):

<DirectoryMatch "\.svn">
    Require all denied
</DirectoryMatch>

Check for the old layout too. Pre-1.7 Subversion scattered a .svn folder (with entries and text-base/) into every directory, not just the root. Blocking any path containing /.svn/ covers both layouts in one rule.

Verify it

curl -s -o /dev/null -w '%{http_code}\n' https://yourdomain.com/.svn/wc.db

You want 404 (or 403) back, never 200. A 200 here means the SQLite database is still downloadable, and your source with it.

Proof

The ApeCyber scanner catches this with a single GET of /.svn/wc.db from the outside, touching nothing. apecyber.com deploys build artifacts to Netlify rather than a working copy, so there is no .svn folder to serve, and it grades A / 100. Closing this is a clean −20 off the posture score.