Safeguard
Application Security•

ASVS 5.0 V13.4.1: Keep .git and .svn Out of Production

ASVS 5.0 V13.4.1 (Level 1) says source control folders must not ship, or must be unreachable. Here is how to build, configure and test for it.

Safeguard Security Team
3 min read

ASVS 5.0 V13.4.1 is a Level 1 requirement. It says your production deployment must either contain no source control metadata (the .git or .svn folders) or make those folders unreachable from the outside and from the application itself.

The simplest way to pass is to never copy them in the first place.

Why it matters

A reachable .git directory is a full copy of your repository history. Tools that dump exposed .git folders will rebuild every file, including old commits where someone once pasted a database password and then deleted it. Deleting a secret from the latest commit does not remove it from history.

This is one of the cheapest findings for an attacker to confirm: one request to /.git/HEAD and a 200 response tells them everything.

How to implement it

Build artifacts, not checkouts. Produce a container image or a release archive from a clean build step and deploy that.

A multi stage Dockerfile does this naturally:

FROM node:20 AS build
WORKDIR /src
COPY . .
RUN npm ci && npm run build

FROM nginx:1.27-alpine
COPY --from=build /src/dist /usr/share/nginx/html

Also add a .dockerignore so a careless COPY . . never picks up metadata:

.git
.svn
.hg
.gitignore

As a second layer, deny dotted paths at the web tier:

location ~ /\.(?!well-known) {
    deny all;
    return 404;
}

If you deploy by running git pull on the server, stop. That practice is the usual reason the folder is there at all.

How to test it

Request the common paths against production and expect a 404 or 403, never a 200:

for p in .git/HEAD .git/config .svn/entries .hg/requires; do
  printf "%s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://example.com/$p"
done

Also inspect the built image: docker run --rm image ls -la /usr/share/nginx/html should show no dotted folders.

Common mistakes

  • Blocking /.git in nginx but forgetting the same rule in the CDN or a second server block.
  • Using git pull as the deploy step.
  • Allowing all dotted paths because .well-known needs to work. Allow only that one.
  • Treating a 403 as safe while the application process itself can still read the folder through a file serving route.

Quick check

Is a 403 on /.git/ enough?

It is acceptable for the external half of the requirement, but removing the folder from the artifact is stronger, because it also covers the application reading it.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.