Is Your Laravel .env File Exposed? How to Check and Fix It

Your Laravel .env file is the single most sensitive file in your entire application. It contains your database credentials, your APP_KEY encryption secret, your mail server passwords, your third-party API keys, and every other secret your app needs to run.

If an attacker can download this file, they don't need to find a vulnerability in your code. They already have the keys to everything.

And this happens far more often than you'd think.

What's Inside a Typical .env File

Here's what a standard Laravel .env file contains:

APP_NAME=MyApp
APP_KEY=base64:abcdefghijklmnopqrstuvwxyz123456=
APP_DEBUG=true

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=myapp
DB_USERNAME=root
DB_PASSWORD=s3cretPassw0rd

MAIL_MAILER=smtp
MAIL_HOST=smtp.mailgun.org
MAIL_USERNAME=postmaster@myapp.com
MAIL_PASSWORD=mailgun-api-key-here

AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLE

STRIPE_SECRET=sk_live_abc123

Every line is a secret an attacker can use. Database credentials give them full access to your data. The APP_KEY lets them decrypt any encrypted values and forge session cookies. AWS keys can spin up infrastructure on your account. A Stripe secret key gives them access to your customers' payment data.

How .env Files Get Exposed

There are four common ways this happens.

1. Web Server Misconfiguration

This is the most common cause. Your web server should point its document root to the public/ directory, not the project root. If the document root is set to /var/www/myapp instead of /var/www/myapp/public, every file in your project is potentially accessible via HTTP, including .env.

Even with the correct document root, some web server configurations don't block access to dotfiles by default.

2. Committed to Git

Developers sometimes commit .env to version control by accident. Even if you remove it later, it remains in your Git history. If your repository is public (or becomes public), anyone can find it.

3. Backup Files Left on Server

Editors and backup processes create files like .env.bak, .env.save, .env.swp, or .env~. Your web server may block access to .env but serve .env.bak without restriction, since it doesn't start with a dot.

4. Directory Traversal Vulnerabilities

A bug in your application or a misconfigured server could allow path traversal attacks. Requests like GET /file?path=../../.env can expose the file even if direct access is blocked.

How to Check If Your .env Is Exposed

Quick Curl Test

Run this from your terminal:

curl -s -o /dev/null -w "%{http_code}" https://yourdomain.com/.env

If this returns 200, your .env file is exposed. You should see 403 or 404.

Also check for common backup variants:

for ext in "" ".bak" ".save" ".old" ".backup" ".swp" "~" ".dist"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://yourdomain.com/.env${ext}")
  echo ".env${ext} -> HTTP ${code}"
done

Check Git History

Search your Git history for accidentally committed .env files:

git log --all --full-history -- .env

If this returns any commits, your .env was committed at some point.

How to Fix It: Nginx

Add this block inside your server directive:

server {
    root /var/www/myapp/public;

    location ~ /\. {
        deny all;
        return 404;
    }

    location ~* \.(bak|save|old|backup|swp|dist)$ {
        deny all;
        return 404;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Test and reload:

sudo nginx -t && sudo systemctl reload nginx

How to Fix It: Apache

Add to your .htaccess or virtual host config:

<FilesMatch "^\.">
    Order allow,deny
    Deny from all
</FilesMatch>

<FilesMatch "\.(bak|save|old|backup|swp|dist)$">
    Order allow,deny
    Deny from all
</FilesMatch>

Set your DocumentRoot correctly:

<VirtualHost *:80>
    DocumentRoot /var/www/myapp/public
</VirtualHost>

What to Do If Your .env Was Exposed

Treat this as a full security breach:

1. Block access immediately. Apply the web server configuration changes above.
2. Rotate every secret. Database passwords, API keys, APP_KEY, mail credentials, third-party tokens. All of them.
3. Check for unauthorized access. Review your database, third-party dashboards, and server logs.
4. Clear all sessions. An attacker with your APP_KEY could have forged session cookies.
5. Set up monitoring. StackShield checks for exposed .env files on every scan so you catch this before attackers do.

Prevention

• Ensure .gitignore includes .env and all variants
• Add a CI/CD check that fails if .env is tracked by git
• Set restrictive file permissions: chmod 600 .env
• Consider using server-level environment variables instead of a .env file in production
• Use automated external monitoring to catch exposure from configuration drift