Laravel apps' .env was readable by the whole world — the most common shared-hosting mistake

A misconfiguration that really happens on shared hosting, with domains and values removed and turned into a lesson. This is not about finding other people's sites — it's about securing your own (or an inherited) deployment.

What was happening

On the shared host, many Laravel apps were laid out this way. Here are the dangerous and correct layouts side by side:

~/public_html/
└── app/          ← whole Laravel (wrong)
    ├── .env      ← readable at /app/.env
    ├── .git/     ← clone restores full history
    ├── vendor/  config/  storage/
    └── public/   ← the ONLY thing meant to be here

~/laravel/app/    ← body outside the web root
├── .env  .git/   ← unreachable over HTTP = safe
└── public/       ← only this, exposed via symlink
        └── index.php

Typical files that returned 200 OK to the outside world:

The three-step fix

Step 1 — First aid: block sensitive files at the HTTP level

First, stop "more leaking." It's reversible and doesn't affect normal pages. Add a deny block at the top of public_html/.htaccess (a defensive config example):

# === SECURITY BLOCK ===
# 404 anything under .env / .git
RedirectMatch 404 (?i)/\.(env|git)(\..*)?(/|$)
 
# deny backups, dumps, credential files
<FilesMatch "(?i)\.(sql|sql\.gz|bak|old|swp|save|orig|tgz)$|^credentials\.json$|\.bk[._]">
    Require all denied
</FilesMatch>
 
# if Laravel internals are visible at /<app>/storage/... etc.
RedirectMatch 403 (?i)^/[^/]+/(storage|bootstrap/cache|config|database|resources|routes|tests|vendor)(/|$)
# === END ===

But a blacklist is fundamentally whack-a-mole. You'll forget composer.lock; new filenames add new holes. Treat it as best-effort first aid, and put the real fix in Step 3.

Step 2 — Rotate keys (assume they were seen)

Even after blocking with .htaccess, treat the secrets as already seen. In priority order:

1. External API keys (top priority, immediate): they map to billing and account takeover. Revoke + re-issue OAuth CLIENT_SECRET, API keys, and cloud credentials, scoped to least privilege.
2. OAuth client secrets.
3. APP_KEY: regenerating can break sessions and make encrypted DB columns undecryptable — check the blast radius first.
4. Mail/SMTP, DB credentials.

Step 3 — Restructure: move the body outside the docroot (the real fix)

Re-lay each app like this:

# 1. Move the body outside the web root (same filesystem → mv is instant, atomic)
mv ~/example/public_html/app  ~/example/app-laravel
 
# 2. Put only a minimal bootstrap in the web root
mkdir -p ~/example/public_html/sub
cat > ~/example/public_html/sub/index.php <<'PHP'
<?php require __DIR__ . '/../../app-laravel/public/index.php';
PHP
# 3. Copy Laravel public/.htaccess, symlink static assets, clear config cache

In this shape, .env, .git, and vendor/ simply don't exist in the web root, so you're safe without relying on .htaccess rules. Full steps are in Keeping .env off the public web on shared hosting.

Traps "not in the textbook"

• Subdomain scope problem: re-pointing a registered subdomain's docroot to another tree via symlink may not follow and returns 500. → Keep the docroot a real directory and require by absolute path from a small index.php inside it (the "bootstrap-redirect" shape) for stability.
• opcache remembers a broken state: opcache can memorize a failed index.php load and keep returning 500 even after you rebuild. Last resort: change the filename (entry.php, etc.).
• An "unregistered" subdomain docroot readable via the parent: https://sub.example/ may be invalid while https://example/sub/ still shows the contents — an easily missed entrance. When inspecting, block the parent-domain path too.
• Hardcoded secrets in config/*.php: combined with a public .git, history reveals every rotation. Always go through env() and never put real values in fallback defaults.

The biggest lesson: this isn't "one person's mistake"

Early shared-hosting culture put everything directly under public_html. Laravel (which expects only public/ exposed) flowed into that, and a dangerous "project under public_html/<app>/, expose its public/" layout became the de-facto standard — vendors' own docs use public_html-based examples, which makes it worse. So fix it with process, not vigilance:

Read next

• Glossary: What is .env · What is a CVE
• Defense: Keeping .env off the public web on shared hosting
• Incident: When a stolen API key got billed for fraud (the other leak path — runtime)