A case where Laravel's .env was publicly readable: a shared-hosting placement mistake and how to fix it

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 needs a new rule for every new file, so something always gets missed. You'll forget composer.lock; new filenames won't be covered. Treat it as a temporary measure, and make the lasting 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 what it affects first.
4. Mail/SMTP, DB credentials.

Step 3 — Restructure: move the body outside the docroot (the root 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.

Problems we hit while fixing it

• 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 path. 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.

Lesson: the default server layout makes this mistake easy

Early shared-hosting practice put everything directly under public_html. When Laravel (which expects only public/ exposed) came into wide use there, 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 helped spread it. 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)
• By framework: Laravel security (.env exposure, APP_DEBUG, authorization)