Finding of the Week: exposed .git directories, backup archives, and config files on production web servers.
This appears in web application assessments more often than it should, and the reason it persists is that it sits at the boundary between development practice and deployment process - an area that rarely gets formal security review.
The mechanic is straightforward. A developer initialises a git repository during local development and deploys the project to a production web server without stripping the .git directory. That directory is now publicly reachable, and tools exist specifically to reconstruct full source code from an exposed .git folder. From there, an attacker has access to your commit history, any secrets that were ever hardcoded, database connection strings, and API keys - including ones that may have been rotated but were committed at some point in the past. Backup archives and leftover config files in web roots carry equivalent risk.
The fix is a deployment hygiene problem, not an architectural one. Web server configurations should explicitly deny access to .git directories, backup file extensions, and any config files not intended to be served. Deployment pipelines should enforce this, not rely on individual developers remembering to exclude files manually. And it should be tested - a basic check for /.git/config on your public-facing applications takes seconds.
If your web applications have never been reviewed for this, it is a low-effort check worth doing before someone else does it for you.