Exposed files on your website: .env, .git, backups and logs

Which files get left in the open

How to check your site

Type your domain followed by each path into a browser: https://your-site.com/.env, https://your-site.com/.git/config, https://your-site.com/wp-content/debug.log or https://your-site.com/var/logs/. The right answer is a 403 (Forbidden) or 404 (Not Found) error. If a file downloads or you can see its contents, it is exposed.

With curl you see only the response code, without downloading anything:

for p in .env .git/config wp-config.php.bak wp-content/debug.log var/logs/ backup.zip; do
  printf "%-28s %s\n" "$p" "$(curl -s -o /dev/null -w "%{http_code}" "https://your-site.com/$p")"
done

Watch out for misleading results: some sites answer 200 with a normal page (a styled "not found" page) for any address. If you get 200, open the path in a browser and see what comes back. Also go through the public folder with your hosting file manager: look for .zip, .sql, .tar.gz and .bak files and folders with names like backup, old or copy.

The free scan tries these paths and other common ones (configuration backups, database dumps, .git, .env, WordPress and PrestaShop logs, directory listings) and tells you which ones are open.

How to fix it

1. Delete or move out of the public folder what should not be there

Backups do not belong in public_html or in any folder served on the web: they go off the server or, at the very least, in a folder above the public root. Leftover test files such as phpinfo.php and .bak copies: delete them. If you deploy with Git, the .git folder should not be on the server; if it has to be, block it.

2. Turn off whatever writes public logs

In WordPress, debug mode is not for a live site. In wp-config.php, WP_DEBUG and WP_DEBUG_LOG should be false. If you need the log for a while, WP_DEBUG_LOG accepts a path outside the public folder instead of true. In PrestaShop, make sure debug mode is off (Advanced Parameters → Performance) and that var/logs/ is not served on the web.

3. Block them on the server

Even if you delete today's files, someone may leave another backup tomorrow. A server rule prevents it. On Apache (and LiteSpeed), in the .htaccess in the site root:

# No directory listings
Options -Indexes

# Hidden files (.env, .git, .htpasswd...) except .well-known
RewriteEngine On
RewriteRule "(^|/)\.(?!well-known/)" - [F]

# Backups, dumps and logs
<FilesMatch "\.(sql|bak|old|orig|save|swp|log|tar|gz|zip)$">
  Require all denied
</FilesMatch>

On Nginx, inside the server block:

autoindex off;

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

location ~* \.(sql|bak|old|orig|save|swp|log|tar|gz|zip)$ {
  deny all;
}

# PrestaShop: logs and cache
location ~ ^/var/ {
  deny all;
}

.htaccess rules only work on Apache and LiteSpeed. If your server runs Nginx, which is common with some hosting providers and on self-managed servers, the rules go in its configuration: ask your provider if you do not have access.

If it was already exposed

Deleting the file closes the door, but you do not know whether someone downloaded it first. Treat it as a leak:

1. Change everything it contained: the database password (and update it in the site's configuration), API, payment and email keys. In WordPress, also regenerate the security keys in wp-config.php.
2. Check the access logs for that path with a 200 response: it tells you whether someone downloaded it and when (grep "/.env" access.log | grep " 200 ").
3. If it was a database backup with customer data, it may be a personal data breach, which under the GDPR has to be reported to the supervisory authority within 72 hours (in Spain, the AEPD; elsewhere, your country's authority). I explain it in data breach at your online store.
4. Check whether the site is compromised: with the database or admin passwords, someone could have got in. The signs are in how to tell if your website is hacked.

If you would rather I do it

The free scan tells you in a few minutes which files you have open. If you want me to fix it, the report + hardening package (€299, excluding VAT) includes the security report and up to three hours to close the urgent issues: deleting or moving the files, adding the server rules and changing the affected keys. With website maintenance, the regular scan warns you if one shows up again.

Sources

• OWASP WSTG: review old backup and unreferenced files for sensitive information (copies with another extension that download as text, compressed archives and editor backup files).
• WordPress: debugging in WordPress (WP_DEBUG_LOG saves debug.log in the content folder, and debugging is not recommended on live sites).
• Apache: access control and the Options directive (-Indexes).
• nginx: access module and autoindex.
• RFC 8615: the /.well-known/ path (reserved paths that must stay accessible).
• AEPD (Spain's data protection authority): personal data breach notification (72-hour deadline; in Spanish).