Fix today

A file with your site's passwords is downloadable

What it means

A .env file is a plain text settings file that many web apps read when they start. It holds lines like DB_PASSWORD=... or STRIPE_SECRET_KEY=...: the passwords and keys your site uses to talk to its database, payment provider, email service and other tools.

It is meant to stay private on the server. We found a file at yoursite.com/.env that reads like one of these settings files, not a normal web page, so the web server hands it to anyone who asks.

This usually happens when a whole project folder is uploaded into the public part of the hosting account, or when the site's "document root" points at the project folder instead of its public subfolder.

Why it matters

Automated tools request /.env on websites all day, every day, because it so often contains working passwords. If the file was readable, assume someone already has a copy.

With those details, a stranger could read or delete your customer database, send email as your business, run up charges on connected cloud services, or use your payment account keys. None of that needs a login to your website.

That is why the order matters. Blocking the file stops new downloads. Changing the passwords and keys makes any copy that was already taken useless.

How to check your own site

1. In a private browser window, go to your own site with /.env on the end, for example https://yoursite.com/.env.
2. If the browser downloads a file or shows lines of text like NAME=value, the file is exposed. Do not paste its contents into email, chat or support tickets.
3. A "403 Forbidden" or "404 Not Found" page, or your normal site, means it is not readable at that address. Check again after every fix, since a cached copy can linger.

How to fix it

Any website

1. Step 1, block it. Use the section below that matches your setup, then confirm that yoursite.com/.env no longer downloads.
2. Step 2, change every secret in the file. Go through it line by line. For each password or key, log in to that service, create a new one, update the site to use it, and then delete or revoke the old one. Start with payment, email and cloud storage keys. Database passwords are usually changed in your hosting control panel.
3. Step 3, check for misuse. Look at recent activity in each service: new users, unusual sign-ins, email sent that you did not send, or unexpected charges. If your hosting keeps access logs, look for successful requests for /.env to see when it was downloaded.

WordPress

1. Standard WordPress keeps its database password in wp-config.php, not in a .env file. A .env usually means a developer tool, a starter kit or a separate app was installed alongside WordPress.
2. Block the file using the cPanel, Cloudflare or server section below, depending on your hosting.
3. Change every secret it lists. If it contains the WordPress database password, change that password in your hosting panel and update wp-config.php or the .env to match, or the site will stop loading.
4. If the file holds WordPress "salts" or keys, generate new ones. This signs everyone out, which is what you want.

Shopify, Squarespace, Wix and other hosted builders

1. These platforms do not let you place a .env file on your domain, so the address we checked is probably served by something else: an old server, a separate app, or a landing page tool.
2. Ask your developer, or check your domain's DNS settings, to find out what is actually answering at that address. Then block the file there and change the secrets, as described above.

cPanel hosting

1. Open File Manager. Under Settings (top right), turn on "Show Hidden Files (dotfiles)". Find .env in public_html or the folder your site runs from.
2. Do not simply delete it, since the site may need it to run. Instead, edit the .htaccess file in that same folder and add the rule shown under "Apache or Nginx" below.
3. Then change the secrets. Database passwords are under MySQL Databases in cPanel. Menu names vary a little between hosts.
4. Under Metrics, Raw Access, you can download access logs and search them for /.env.

Cloudflare

1. If your site runs through Cloudflare, go to Security, then WAF, then Custom rules (names vary slightly between plans and dashboard versions).
2. Create a rule where the URI Path contains /.env, with the action Block. This takes effect within seconds.
3. Treat it as a fast first step. The file is still on your server and can be reached around Cloudflare, so block it there too, and change the secrets.

Apache or Nginx

1. On Apache, add the rule below to the .htaccess file in your site's public folder, or to the site configuration. It blocks .env and variants like .env.production.
2. On Nginx, add the location block inside the server block for your site, test the configuration with nginx -t, and reload.
3. The better long-term fix is to move the file above the public folder, so the web server never serves it at all. EverThread checks for an exposed .env every day, so you will hear quickly if it comes back.

# Apache 2.4 (.htaccess or site config)
<FilesMatch "^\.env">
  Require all denied
</FilesMatch>

# Nginx (inside the server block)
location ~ /\.env {
  deny all;
}

What to send your developer

/.env is served publicly. Deny it at the web server now, then rotate every credential in the file: database users, API keys, SMTP passwords, cloud access keys and app secrets. Some app secrets, such as a framework encryption key, protect stored data, so plan that rotation rather than just swapping the value. Set the document root to the app's public directory (for example public/) so the file lives outside it. Review access logs for 200 responses to /.env to estimate exposure, and check each connected service for activity since the file went live. Blocking all dotfiles except .well-known covers .git and similar files too.

# Nginx: block all dotfiles except .well-known
location ~ /\.(?!well-known) {
  deny all;
}

Common questions