Un caso en que el .env de Laravel era legible públicamente: un error de ubicación en hosting compartido y cómo corregirlo

Una mala configuración que sí ocurre en hosting compartido, con dominios y valores eliminados y convertida en lección. Esto no trata de encontrar los sitios de otras personas — trata de asegurar tu propio despliegue (o uno heredado).

Qué estaba pasando

En el host compartido, muchas apps Laravel estaban dispuestas así. Aquí están las disposiciones peligrosa y correcta una al lado de la otra:

~/public_html/
└── app/          ← todo Laravel (incorrecto)
    ├── .env      ← legible en /app/.env
    ├── .git/     ← clonar restaura el historial completo
    ├── vendor/  config/  storage/
    └── public/   ← lo ÚNICO que debería estar aquí

~/laravel/app/    ← cuerpo fuera de la raíz web
├── .env  .git/   ← inalcanzable por HTTP = seguro
└── public/       ← solo esto, expuesto vía enlace simbólico
        └── index.php

Archivos típicos que devolvían 200 OK al mundo exterior:

La corrección en tres pasos

Paso 1 — Medida de urgencia: bloquea los archivos sensibles a nivel HTTP

Primero, detén «que se filtre más». Es reversible y no afecta a las páginas normales. Añade un bloque deny al principio de public_html/.htaccess (un ejemplo de configuración defensiva):

# === SECURITY BLOCK ===
# 404 a cualquier cosa bajo .env / .git
RedirectMatch 404 (?i)/\.(env|git)(\..*)?(/|$)
 
# denegar copias de seguridad, volcados, archivos de credenciales
<FilesMatch "(?i)\.(sql|sql\.gz|bak|old|swp|save|orig|tgz)$|^credentials\.json$|\.bk[._]">
    Require all denied
</FilesMatch>
 
# si las internas de Laravel están visibles en /<app>/storage/... etc.
RedirectMatch 403 (?i)^/[^/]+/(storage|bootstrap/cache|config|database|resources|routes|tests|vendor)(/|$)
# === END ===

Pero una lista negra necesita una regla nueva para cada archivo nuevo, así que siempre se escapa algo. Olvidarás composer.lock; los nombres de archivo nuevos no quedarán cubiertos. Trátalo como una medida temporal, y haz la corrección duradera en el Paso 3.

Paso 2 — Rotar claves (asume que las vieron)

Incluso tras bloquear con .htaccess, trata los secretos como ya vistos. Por orden de prioridad:

1. Claves de API externas (máxima prioridad, inmediato): se asocian a facturación y toma de control de cuentas. Revoca + reemite el CLIENT_SECRET de OAuth, las claves de API y las credenciales de la nube, con alcance de mínimo privilegio.
2. Secretos de cliente OAuth.
3. APP_KEY: regenerarlo puede romper sesiones y dejar indescifrables columnas de BD cifradas — comprueba primero a qué afecta.
4. Correo/SMTP, credenciales de BD.

Paso 3 — Reestructurar: mover el cuerpo fuera del docroot (la corrección de fondo)

Vuelve a disponer cada app así:

# 1. Mover el cuerpo fuera de la raíz web (mismo sistema de archivos → mv es instantáneo, atómico)
mv ~/example/public_html/app  ~/example/app-laravel
 
# 2. Poner solo un bootstrap mínimo en la raíz 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. Copiar public/.htaccess de Laravel, enlazar simbólicamente los activos estáticos, limpiar la caché de config

En esta forma, .env, .git y vendor/ simplemente no existen en la raíz web, así que estás a salvo sin depender de reglas de .htaccess. Los pasos completos están en mantener .env fuera de la web pública en hosting compartido.

Problemas que encontramos al corregirlo

• Problema de alcance de subdominio: reapuntar el docroot de un subdominio registrado a otro árbol vía enlace simbólico puede no seguirse y devolver 500. → Mantén el docroot como un directorio real y haz require por ruta absoluta desde un pequeño index.php dentro de él (la forma «bootstrap-redirect») para estabilidad.
• opcache recuerda un estado roto: opcache puede memorizar una carga fallida de index.php y seguir devolviendo 500 incluso tras reconstruir. Último recurso: cambia el nombre del archivo (entry.php, etc.).
• Un docroot de subdominio «no registrado» legible vía el padre: https://sub.example/ puede ser inválido mientras https://example/sub/ aún muestra el contenido — una ruta fácil de pasar por alto. Al inspeccionar, bloquea también la ruta del dominio padre.
• Secretos incrustados en config/*.php: combinado con un .git público, el historial revela cada rotación. Pasa siempre por env() y nunca pongas valores reales en los defaults de respaldo.

Lección: la disposición por defecto del servidor facilita este error

La práctica temprana del hosting compartido ponía todo directamente bajo public_html. Cuando Laravel (que espera exponer solo public/) se extendió allí, una disposición peligrosa de «proyecto bajo public_html/<app>/, exponer su public/» se convirtió en el estándar de facto — la propia documentación de los proveedores usa ejemplos basados en public_html, lo que ayudó a extenderla. Así que corrígelo con proceso, no con vigilancia:

Leer a continuación

• Glosario: qué es .env · qué es un CVE
• Defensa: mantener .env fuera de la web pública en hosting compartido
• Framework: seguridad de Laravel (los tres grandes fallos: .env, APP_DEBUG, autorización)
• Incidente: cuando una clave de API robada se facturó de forma fraudulenta (la otra vía de fuga — en tiempo de ejecución)