.env and .git files on your server: what scanners look for

In my server logs I regularly see requests for addresses that don’t exist on the website: /.env, /.git/config, /backup.zip, /phpinfo.php. These aren’t customers or search engines but automated scanners. They query thousands of business websites one after another and check whether someone has left a file with passwords or a copy of the entire website on the server.

If such a file is accessible, a single download is enough: the database password, the email key or a copy of customer data ends up with a stranger. In this guide I show what scanners look for, how to check your own website in 10 minutes and how to block these files.

What scanners look for

The same addresses keep appearing in the logs of many servers. Each of them is a file that sometimes stays in the website directory after a deployment or an update.

An important difference: the server runs the wp-config.php file as a program, so its contents aren’t visible from outside. A copy of it with a different extension (.bak, .old, .txt) is just an ordinary text file that the browser will simply display or download.

How these files end up on the server

Nobody leaves them there on purpose. I most often see five scenarios:

1. Deployment by copying the whole project folder. Along with the website files, the hidden .git directory and the .env file end up on the server.
2. A “temporary” backup before an update. Someone packs the website into backup.zip in the website directory and forgets to delete it.
3. Editor backups. The editor leaves files ending in ~, .bak or .swp next to the edited file.
4. An old version of the website in a subdirectory. After a website change, the previous one lands in /old/ or /test/ and keeps running, often without updates.
5. Backups in the public directory. Some backup tools save archives in a place that can be reached from a browser.

How to check your website in 10 minutes

Check only your own website or a website you look after with the owner’s authorization.

Step 1: type the addresses into your browser. Replace yourdomain.pl with your address and open them one by one:

https://yourdomain.pl/.env
https://yourdomain.pl/.git/config
https://yourdomain.pl/.git/HEAD
https://yourdomain.pl/backup.zip
https://yourdomain.pl/phpinfo.php

A good result is a 403 or 404 error. A bad result is the file’s contents being displayed or a download starting.

Step 2: go through the website directory. Log in to the file manager in your hosting panel (or via FTP) and open the website directory, usually public_html or www. Look for files ending in .zip, .sql, .tar.gz, .bak, .old and directories named old, test, kopia.

Step 3: check for file listings in directories. Open the address of a directory that holds images, e.g., https://yourdomain.pl/wp-content/uploads/ in WordPress. If you see a list of files instead of a blank page or an error, the server shows the contents of directories to every visitor.

You’ll find a broader review of your website, not only for these files, in the guide on how to check your business website for free.

What to do if a file is accessible

If any of the addresses showed content, act in this order:

1. Delete the file or move it outside the website directory. Backups shouldn’t sit in a place accessible from the internet.
2. Treat the passwords from that file as exposed. Change the database password, generate new API keys and revoke the old ones, and change the password to the mailbox used by the website. In WordPress, also generate new authentication keys and salts, which will log out everyone who is logged in.
3. Ask your host for the logs. Ask whether anyone downloaded that address (server response 200). This will show whether the file leaked or just sat there.
4. Assess whether personal data leaked. If the backup contained a database with customer data, this may be a personal data breach. Article 33 of the GDPR requires notifying the President of UODO (Urząd Ochrony Danych Osobowych, Poland’s data protection authority) without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Information and the form are available at uodo.gov.pl.

I describe the full plan for the first day after discovering a problem in the guide business website vulnerability: what to do in the first 24 hours.

Blocking in the server configuration

Deleting the files is the basis, but it’s also worth blocking such addresses permanently. Then a file uploaded by accident won’t be accessible.

Apache (many shared hosting plans), the .htaccess file in the website directory:

# No file listings in directories
Options -Indexes

# Files and directories starting with a dot (.env, .git), except .well-known
RedirectMatch 404 /\.(?!well-known)

# Backups and dumps that shouldn't be in the website directory
<FilesMatch "(\.(sql|bak|old|swp)|~)$">
  Require all denied
</FilesMatch>

Three notes before pasting:

• Make a copy of your current .htaccess and open the website right after the change. Some hosts don’t allow the Options line, and then the website will show a 500 error. Remove that line and ask your host how to turn off file listings.
• Require all denied works in Apache 2.4, that is, on the vast majority of today’s servers.
• The exception for .well-known is needed because, among other things, SSL certificate renewal works through it.

Nginx (VPS servers, the change is made by the administrator):

location ~ /\.(?!well-known) {
    deny all;
}

location ~* \.(sql|bak|old|swp)$ {
    deny all;
}

After the change and after deleting unnecessary files, repeat step 1 of the check: all addresses should return 403 or 404.

How to prevent this in the future

• Upload only the website files to the server, without the .git directory, project files and notes. Deployment tools have an exclusion list for this.
• Keep .env outside the public directory. Frameworks such as Laravel have a separate public directory, and only that directory should be visible from the internet, while the .env file sits one level up.
• Store backups outside the website directory and off the server. I describe how to organize this in the guide on website backups and the 3-2-1 rule.
• Clean up after every update: delete test files, archives and old versions of the website.
• Repeat the check from this guide once a quarter. It takes 10 minutes, and scanners don’t take breaks.

Summary

Scanners look for files left on the server by accident, and they do it automatically, regardless of company size. Check the five addresses from this guide, delete unnecessary backups and add a block in the server configuration. If you’d rather have someone do it for you, I’ll check your website and server as part of a security audit, and ongoing protection comes with technical maintenance. You can also simply write to me.