O .env de apps Laravel era legível pelo mundo inteiro — o erro mais comum de hospedagem compartilhada

Uma configuração incorreta que realmente acontece em hospedagem compartilhada, com domínios e valores removidos e transformada em lição. Isto não é sobre encontrar os sites de outras pessoas — é sobre proteger seu próprio deploy (ou um herdado).

O que estava acontecendo

No host compartilhado, muitos apps Laravel estavam dispostos assim. Eis os layouts perigoso e correto lado a lado:

~/public_html/
└── app/          ← Laravel inteiro (errado)
    ├── .env      ← legível em /app/.env
    ├── .git/     ← clone restaura o histórico completo
    ├── vendor/  config/  storage/
    └── public/   ← a ÚNICA coisa que deveria estar aqui

~/laravel/app/    ← corpo fora da raiz web
├── .env  .git/   ← inacessível por HTTP = seguro
└── public/       ← só este, exposto via symlink
        └── index.php

Arquivos típicos que retornavam 200 OK para o mundo externo:

A correção em três passos

Passo 1 — Primeiros socorros: bloqueie arquivos sensíveis no nível do HTTP

Primeiro, pare "mais vazamento". É reversível e não afeta as páginas normais. Adicione um bloco de deny no topo do public_html/.htaccess (um exemplo de configuração defensiva):

# === 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 ===

Mas uma blacklist é fundamentalmente enxugar gelo. Você vai esquecer o composer.lock; novos nomes de arquivo adicionam novos buracos. Trate-a como primeiros socorros de melhor esforço e coloque a correção real no Passo 3.

Passo 2 — Rotacione as chaves (suponha que foram vistas)

Mesmo depois de bloquear com o .htaccess, trate os segredos como já vistos. Em ordem de prioridade:

1. Chaves de API externas (prioridade máxima, imediato): elas mapeiam para cobrança e tomada de conta. Revogue + reemita o CLIENT_SECRET OAuth, chaves de API e credenciais de nuvem, com escopo de menor privilégio.
2. Segredos de cliente OAuth.
3. APP_KEY: regenerar pode quebrar sessões e tornar colunas de DB criptografadas indecifráveis — verifique o raio de explosão primeiro.
4. E-mail/SMTP, credenciais de DB.

Passo 3 — Reestruture: mova o corpo para fora da docroot (a correção real)

Redisponha cada app assim:

# 1. Mova o corpo para fora da raiz web (mesmo sistema de arquivos → mv é instantâneo, atômico)
mv ~/example/public_html/app  ~/example/app-laravel
 
# 2. Coloque só um bootstrap mínimo na raiz web
mkdir -p ~/example/public_html/sub
cat > ~/example/public_html/sub/index.php <<'PHP'
<?php require __DIR__ . '/../../app-laravel/public/index.php';
PHP
# 3. Copie o public/.htaccess do Laravel, faça symlink dos assets estáticos, limpe o cache de config

Nesta forma, .env, .git e vendor/ simplesmente não existem na raiz web, então você fica seguro sem depender de regras do .htaccess. Os passos completos estão em Mantendo o .env fora da web pública em hospedagem compartilhada.

Armadilhas "que não estão no manual"

• Problema de escopo de subdomínio: repontar a docroot de um subdomínio registrado para outra árvore via symlink pode não seguir e retornar 500. → Mantenha a docroot um diretório real e faça require por caminho absoluto a partir de um pequeno index.php dentro dele (a forma "bootstrap-redirect") para estabilidade.
• opcache lembra de um estado quebrado: o opcache pode memorizar uma falha de carga do index.php e seguir retornando 500 mesmo depois de você reconstruir. Último recurso: troque o nome do arquivo (entry.php, etc.).
• Uma docroot de subdomínio "não registrado" legível pelo pai: https://sub.example/ pode ser inválido enquanto https://example/sub/ ainda mostra o conteúdo — uma entrada facilmente esquecida. Ao inspecionar, bloqueie também o caminho do domínio-pai.
• Segredos hardcoded em config/*.php: combinados com um .git público, o histórico revela cada rotação. Sempre passe por env() e nunca coloque valores reais em defaults de fallback.

A maior lição: isto não é "o erro de uma pessoa"

A cultura inicial de hospedagem compartilhada colocava tudo diretamente sob o public_html. O Laravel (que espera só o public/ exposto) entrou nisso, e um layout perigoso de "projeto sob public_html/<app>/, expor seu public/" virou o padrão de fato — a própria documentação dos fornecedores usa exemplos baseados em public_html, o que piora. Então corrija com processo, não vigilância:

Leia a seguir

• Glossário: O que é o .env · O que é um CVE
• Defesa: Mantendo o .env fora da web pública em hospedagem compartilhada
• Incidente: Quando uma chave de API roubada foi cobrada por fraude (o outro caminho de vazamento — em tempo de execução)