There is a file sitting in many web applications called .env. It contains database passwords, API keys for payment processors and email services, and secret tokens that authenticate your application to third-party platforms. In thousands of cases, it sits openly on the internet — readable by anyone who knows to look.

And attackers always know to look.

What Is a .env File?

When developers build web applications, they store configuration values that should be kept secret in a .env file rather than hardcoding them into the application code. A typical .env file might contain:

DB_PASSWORD=s3cr3tpassword123
STRIPE_SECRET_KEY=sk_live_abc123...
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
MAIL_PASSWORD=smtp_password_here
APP_SECRET=random_secret_token_here

This file should never be publicly accessible. It is meant to exist only on the server, loaded by the application at runtime. But misconfiguration is common — and automated scanning tools check for exposed .env files within minutes of a new site going live.

How Attackers Find Exposed .env Files

A request to https://yourwebsite.co.uk/.env is one of the first things automated attack tools try. If the server responds with the contents of the file rather than a 403 (Forbidden) or 404 (Not Found), the attacker has everything they need.

Security researchers have observed that newly deployed websites are probed for .env files within minutes of going live. These scans run 24 hours a day.

A 2022 Truffle Security report revealed that over 4,000 unique .env files had been inadvertently committed to public GitHub repositories, exposing thousands of live API keys and credentials for AWS, Slack, Stripe, SendGrid, Twilio, and others — many of which were still valid at time of discovery. Research by GitGuardian found that in 2023 alone, over 12.8 million new secrets were detected in public GitHub repositories — a number that grows year on year.

What Happens When Attackers Get In?

The consequences depend on what is in the file, but they can be severe:

Database access. With database credentials, an attacker can download your entire customer database — names, addresses, email addresses, purchase history, and potentially payment data. This is a reportable data breach under UK GDPR.

Cloud storage access. AWS, Google Cloud, and Azure credentials can be used to download or delete all your stored files, run up enormous cloud computing bills (cryptomining is common), or pivot to other connected systems. AWS bills from credential theft have cost businesses hundreds of thousands of pounds.

Payment processor access. Stripe or PayPal API keys can be used to access customer payment data or issue fraudulent refunds.

Email service hijacking. SMTP or transactional email API keys can be used to send millions of phishing emails from your domain, destroying your sending reputation.

Account takeover. Application secret keys can be used to forge authentication tokens, granting admin access to your entire application.

Real-World Cases

In 2020, attackers exploited exposed Laravel .env files at scale, targeting businesses that had deployed the PHP framework without securing the environment file. Laravel applications use .env files extensively, and a misconfigured deployment leaves the file directly accessible at the web root.

This is similar in nature to the exposed Git repository risk — both involve developer files reaching the public web that should never be served.

What to Do Next

  • Check right now whether your .env file is accessible. Visit https://yourwebsite.co.uk/.env in your browser. If you see configuration values, act immediately.
  • Block access at the server level. In Nginx, add location ~ /\.env { deny all; } to your server block. In Apache, use .htaccess to deny access to the file.
  • Move sensitive files above the web root. The most robust solution is to store .env in a directory that is not publicly served at all.
  • Rotate any credentials that may have been exposed. If there is any possibility the file was publicly accessible, assume it was read. Change every password, regenerate every API key, and rotate every secret token immediately.
  • Check your .gitignore. Ensure .env is listed so it is never accidentally committed to a version control repository.
  • Audit other sensitive files. Similar risks apply to database backup files, configuration files, and log files sitting in your web root.

Finding an exposed .env file is one of the most common critical findings in website security assessments — and one of the easiest to prevent.

W3IT’s free security check tests whether your .env file and other sensitive configuration files are publicly accessible. Run it now — because attackers are probably already checking.