Researchers highlighted a failure mode in Azure App Service’s “Local Git” deployment on the Linux/in-process stacks (PHP, Python, Node, Ruby): the deployed repository, including its hidden .git folder, lands in the same content root the web server serves to the internet. When the runtime serves files from that root, a request for /.git/config or the packed objects can return them — and from those, an attacker reconstructs your full source tree and commit history.

Why this is worse than it sounds

Source code is not just intellectual property; it is a map. Commit history routinely contains hard-coded credentials, connection strings, API keys, internal endpoints and the exact logic of your authorization checks. Once .git is downloadable, an attacker clones your repository as it existed at every commit — including the secret you committed once and “removed” in the next commit, which lives forever in history.

How to check and contain it

From outside, request https://your-app/.git/HEAD: a response containing ref: refs/heads/main means the directory is exposed. Contain it by ensuring the web root and the deployment root are not the same directory, by blocking dotfiles at the server, and by deploying through a build pipeline that ships artifacts, not a working repository.

# quick external check — a 200 here is a finding
curl -s https://your-app.azurewebsites.net/.git/HEAD

# block dotfiles at the edge so .git is never served
location ~ /.(?!well-known) { deny all; }

The Never Trust reading

The lesson is not “Azure is unsafe” — it is that platform defaults are not a security boundary. A convenience designed for fast deploys quietly changed what was reachable from the public internet. B5 Secure is built on the assumption that the environment will surprise you: protect each resource on its own merits, never infer safety from where something is hosted, and verify rather than trust the platform to have done the right thing.