DEV Community

Please remove that .git folder

spO0q 🐒🎃 on June 22, 2022

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 ...
Collapse
 
corentinbettiol profile image
Corentin Bettiol

Here's my config on my website:

<VirtualHost *:443>

        ServerName ***
        Serveralias ***

        ServerAdmin ***
        DocumentRoot /var/***/***/***/***

        Options FollowSymLinks MultiViews

        ErrorDocument 404 /***/404
        RedirectMatch 404 /\.git  # <-- THIS LINE HERE

        [...]
Enter fullscreen mode Exit fullscreen mode

And it works well :)

It works!

Collapse
 
corentinbettiol profile image
Corentin Bettiol • Edited

(I use it in my sites-enabled/ folder because adding .htaccess files are slowing down apache and my server is not very powerful :P)

You should avoid using .htaccess files completely if you have access to httpd main server config file. Using .htaccess files slows down your Apache http server. Any directive that you can include in a .htaccess file is better set in a Directory block, as it will have the same effect with better performance.
httpd.apache.org/docs/2.4/howto/ht...

The httpd.conf is parsed one time. If you use .htaccess it'll get hit every time something is called. That'll cause a fairly large performance hit that will just get worse with increasing requests.
stackoverflow.com/a/25064109/6813732

Collapse
 
spo0q profile image
spO0q 🐒🎃

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 .htaccess would slow down the entire architecture, especially your number of hits.

Thread Thread
 
corentinbettiol profile image
Corentin Bettiol • Edited

I haven't done any test on my server, but I will quote another SO answer:

Also, when [.htaccess is] enabled the server will take a potential performance hit. The reason is because, every server request, if .htaccess support is enabled, when Apache goes to fetch the requested file for the client, it has to look for a .htaccess file in every single directory leading up to wherever the file is stored.
stackoverflow.com/a/29114826/6813732

Collapse
 
mrwensveen profile image
Matthijs Wensveen

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. 👍

Collapse
 
spo0q profile image
spO0q 🐒🎃

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 :)

Collapse
 
mrwensveen profile image
Matthijs Wensveen

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.

Collapse
 
dendihandian profile image
Dendi Handian

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.

Collapse
 
rx40 profile image
Petrus-Nauyoma

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.

Collapse
 
darkain profile image
Vincent Milum Jr

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.

Collapse
 
ytjchan profile image
ytjchan

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.

Collapse
 
phlash profile image
Phil Ashby

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, ...).

Collapse
 
spo0q profile image
spO0q 🐒🎃 • Edited

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.

Collapse
 
slidenerd profile image
slidenerd • Edited

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

Collapse
 
spo0q profile image
spO0q 🐒🎃 • Edited

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.txt or 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.

Collapse
 
seancassiere profile image
Sean Cassiere

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.

Collapse
 
spo0q profile image
spO0q 🐒🎃

Yes, it's easy to git pull your project and forget that :(

Collapse
 
mikcat profile image
mikcat

I'm used to add this to the main apache config:

<DirectoryMatch "/\.git">
   Require all denied
</DirectoryMatch>
Enter fullscreen mode Exit fullscreen mode
Collapse
 
spo0q profile image
spO0q 🐒🎃 • Edited

EDIT: your example is better than mine.

Collapse
 
lokaimoma profile image
Kelvin Clark

Wow this is very informative.

Collapse
 
pandademic profile image
Pandademic

Lovely article!

Collapse
 
jingxue profile image
Info Comment hidden by post author - thread only accessible via permalink
Jing Xue

If your .git gets 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.

Collapse
 
spo0q profile image
Info Comment hidden by post author - thread only accessible via permalink
spO0q 🐒🎃

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.

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
jingxue profile image
Info Comment hidden by post author - thread only accessible via permalink
Jing Xue

Lol. Looks like my comment was hidden too.

The point is that .git should 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.

 
Sloan, the sloth mascot
Comment deleted
 
Sloan, the sloth mascot
Comment deleted
 
jingxue profile image
Info Comment hidden by post author - thread only accessible via permalink
Jing Xue

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 .git folder. The impression you are making is that having .git deployed is an acceptable scenario, and the solution is to control access. My point is exactly that having .git deployed 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.

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
Sloan, the sloth mascot
Comment deleted
 
Sloan, the sloth mascot
Comment deleted
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
bosz profile image
Fongoh Martin T.

Thank you

Collapse
 
ricardochan profile image
Ricardo Chan

Great tip!

Collapse
 
randellbrianknight profile image
Randell Brian Knight

Thanks for sharing this excellent git security information and hardening tips.

Collapse
 
christiankozalla profile image
Christian Kozalla

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?

Collapse
 
christiankozalla profile image
Christian Kozalla

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?

Collapse
 
spo0q profile image
spO0q 🐒🎃 • Edited

when deploying your website on the server with a basic git pull and the .git/ folder is publicly accessible. It happens a lot.

Thread Thread
 
christiankozalla profile image
Christian Kozalla

Ah, I see!

Collapse
 
ssergdev profile image
SergDev

Why would anyone deploy the .git folder?

Collapse
 
spo0q profile image
spO0q 🐒🎃

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.

Some comments have been hidden by the post's author - find out more