Introduction
I had just finished migrating my web server to an Nginx container. Ports were bound, host volumes mounted, firewall rules configured. Everything looked solid. I could reach my site and all its glorious pages without issue.
Feeling good, I switched gears to document the setup. But there was something I overlooked. While checking my Nginx access logs, I noticed something strange—requests hitting paths like:
/\.git/HEAD /\.git/logs
…and returning 200 OK.
These should never be served publicly!
My first thought? I got hacked. I started digging through logs, trying to figure out how someone got in, what they accessed, and how bad it was. It looked like someone was pulling internal repo files directly from my server.
Then it hit me. I wasn’t hacked. There was no exploit. No unauthorized access. I had been serving my entire Git repository to the internet the whole time.
What Happened
The issue came down to how I deployed the site. I cloned my Git repository directly into the Nginx web root (/srv/www/nginx) so the container could serve the files. This worked for serving the site—but it also meant the .git directory was inside the web-accessible path.
Lesson Learned
In the end, I decided to completely relocate the git repo to another location. This highlights an important distinction between a working directory and a deployment directory. Always make sure sensitive directories like .git are never served publicly!