Have you ever tried to browse http://yoursite.com/.git/?
If you get a 403 error, that's normal. It means directory browsing is disabled, which is ...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Here's my config on my website:
And it works well :)
(I use it in my
sites-enabled/folder because adding.htaccessfiles are slowing down apache and my server is not very powerful :P)hello, the good news is you can manage it wherever you want, but do you have any figures or test results for the performances? I'd be curious to know why
.htaccesswould slow down the entire architecture, especially your number of hits.I haven't done any test on my server, but I will quote another SO answer:
My advice would be to never have the website root at the project root. Always use a www, html, public, or even src subdirectory. This way, the .git directory and files like README.md are not exposed to the internet.
If you deploy by using git pull on the server and your hosting provider only provides a webroot, this article has good advice. 👍
Totally on point: no public access! I wrote this post for those who do not have that in mind. In fact, even if you are on a budget, you don't have to deploy such folder. It's just more convenient for many people, but not mandatory. There are other ways to sync you code.
The problem with cybersecurity is you don't always have the best conditions, so many people will tell you "don't put anything sensitive in git, etc," which it's true in a perfect world, but sometimes more difficult to achieve in reality.
I prefer having several layers, and if I can remove that .git folder from public folder, I'll do it :)
Absolutely! Sometimes hosting providers don't give a lot of options on how or where to deploy. Or maybe someone isn't even aware that this is problematic.
Maybe a web.config equivalent of this article would be useful as well, for those who use IIS.
this is a kind of fear that would happened if I build a code from scratch by myself without understanding web security. for the security, I always rely on frameworks.
I totally get you. Imagine leaking api keys in the env folder. Frameworks really help to get on your feet a bit quicker. Otherwise all these little but disastrous security details are hard to come by especially without a patient senior mentor/dev.
A better strategy: don't put sensitive credentials in your git repos to begin with.
The .htaccess recommendation is limited in what servers even support that directive. There are methods to do it with others, but this becomes a separate security nightmare of making sure infrastructure never changes over time (which is within itself a different bad practice)
Security credentials should be stored using a dedicated secrets manager outside of the repo. This is especially true because dev/staging/test/prod/etc should all have separate credentials ANYWAYS, so mish-mashing them all together in the repo with conditions isn't best practices to begin with.
Some info can be stored in .git folder such as commit user name and email using
git config, which defaults to storing them into .git/config.Good layered defence approach! I would also advocate for automating deployment to always use a safe export mechanism (eg: git archive) that omits the internals of the source control.
For cloud-hosted deployments, your provider of choice will likely have an arsenal of tools to help deploy stuff (typically workflow pipelines, secret management, versioning, auto-rollbacks, ...).
Indeed. Nice suggestion.
It's true that providers offer an extensive range of configurations and tools to automate deployments, but it's kinda the same problem if you misuse them or misconfigure security settings.
Besides, if hackers manage to steal access to those interfaces, which happens a lot, it's game over too.
In a nutshell, I agree with you on automation but admins should be careful with their credentials and ensure they understand how the cloud-based system works.
Some whitehat hacker reading this should run a brute force bot to traverse every website out there and make a list of the ones that did hit the .git folder, extract their admin emails and send them an automated message or at the easiest make a list of them similar to haveibeenpwned.com i think
yeah, people always forget that, in git data, hackers do not look for hard coded keys or database credentials only, there are so many valuable information you can get...
Unfortunately, while your suggestion could make sense, it's hard to determine whether you have a white or a grey hat approach here (I would say grey). If the website does not include any
security.txtor does not explicitly invite white hackers to test the website (e.g. bug bounty) and contact them, it might be considered illegal in many countries.It's funny, because I've been using cloud providers for deploying my frontends, with the backends requiring me to allow folders to be publicly accessible, and therefore haven't dealt with/or even though about this aspect of security before.
Could definitely see this affecting beginners and students, that use static plain HTML or PHP websites deployed.
Yes, it's easy to
git pullyour project and forget that :(I'm used to add this to the main apache config:
EDIT: your example is better than mine.
Wow this is very informative.
Lovely article!
If your
.gitgets deployed, your DevOps engineer ought to be fired.It's as simple as this: "do not deploy .git".
All this access blocking business is pointing in the wrong direction.
Security is not "as simple as this." When the damage is done, firing people is just a consequence, not a solution. Besides, if you read the post, you'll see it explicitly says "don't deploy git". Blocking is just an additional layer of protection for those who don't have that knowledge, the possibility to change configurations, or DevOps to fire.
Lol. Looks like my comment was hidden too.
The point is that
.gitshould not be deployed whatsoever, which should have been easily verifiable in a lower environment before it gets into production, so there should not be a scenario where you have to scramble to block access to it.Lol, you mention "don't deploy the .git/ folder" once, and spend literally the rest of the post talking about blocking access to a deployed
.gitfolder. The impression you are making is that having.gitdeployed is an acceptable scenario, and the solution is to control access. My point is exactly that having.gitdeployed to a production server is not acceptable under no circumstances, and that there ought not be any scenario where this even accidentally happens, because any proper CI process should catch it.Thank you
Great tip!
Thanks for sharing this excellent git security information and hardening tips.
I suppose that you'd only expose your .git directory if there is no build step before deployment or if you'd put the .git directory into the public directory?
I have to admit: I cannot intentionally deploy my .git directory, even if I try! So could you please explain to me, how I would get into such a situation?
when deploying your website on the server with a basic
git pulland the.git/folder is publicly accessible. It happens a lot.Ah, I see!
Why would anyone deploy the .git folder?
It's a bad practice that happens all the time unfortunately. It's easy to use git to pull a repository on a public folder in production. Sounds crazy, but I've seen it multiple times in my career.
Major flaw, and it's not a question of big companies vs. small businesses. It only depends on the practices.