Por framework
Seguridad de Laravel — exposición de .env, APP_DEBUG y autorización
Los tres grandes fallos de seguridad de Laravel — .env expuesto desde el directorio público, APP_DEBUG activado en producción y autorización ausente (IDOR / Mass Assignment) — y cómo cerrar cada uno. Defensivo, sin pasos de ataque.
Para: cualquiera que gestione una app Laravel. Aquí no hay pasos de ataque — solo los tres grandes incidentes operativos y cómo cerrarlos. Para el panorama completo, mira el centro de seguridad por framework.
Los tres grandes fallos (donde los valores por defecto no te salvan)
El escapado y la autenticación de Laravel son excelentes, pero estos tres son tuyos para cerrar.
① Secretos expuestos
.env, copias de seguridad o claves alcanzables por URL desde public/. Un desliz de ubicación = fuga instantánea.
② Debug activado en producción
APP_DEBUG=true expone variables de entorno e info de conexión en la página de error. Extraído mediante errores deliberados.
③ Autorización ausente
Autenticado pero sin alcance de propietario (IDOR) / Mass Assignment sobrescribiendo is_admin, etc.
Cómo cerrarlos (3 pasos)
Mueve los secretos fuera del directorio público (permisos 600)
.env fuera de la raíz del documento, pero no dejes caer por accidente copias de seguridad, exportaciones o archivos de claves en public/. Mantén los secretos fuera de la raíz de la app con permisos 600 (solo el propietario). (→ mantén los secretos fuera de los directorios públicos · un caso completo de exposición de .env)Desactiva debug + cachea la config en producción
APP_DEBUG=false y APP_ENV=production. Fíjalo con una caché de config y detén que se muestren errores detallados hacia el exterior. Intégralo en los pasos de despliegue y verifícalo cada vez.Construye la autorización (Policy/Gate + $fillable)
$fillable para evitar que se sobrescriban campos no previstos. (→ qué es IDOR)Común (peligroso)
- copias de seguridad o claves colocadas en
public/, alcanzables por URL - producción dejada en
APP_DEBUG=true - sin autorización — «con sesión iniciada = puede ver»
Model::create($request->all())aceptando todos los campos
Correcto
- secretos fuera de la raíz del documento con permisos 600
- producción con debug apagado + caché de config
- alcance de propietario con Policy/Gate
- declarar
$fillablepara bloquear el Mass Assignment
La visión de este sitio: sólido hasta los valores por defecto; la autorización corre por tu cuenta
Laravel tiene muchos buenos valores por defecto, pero la autorización — quién puede hacer qué — es específica de la app, así que ningún framework puede protegerla de forma automática. Los incidentes que seguimos viendo son menos SQLi o XSS que del tipo «autenticado, pero sin comprobación de propiedad». Por eso el centro de gravedad no es una configuración llamativa sino el trabajo poco vistoso de dar alcance a cada lectura/actualización por propietario. Suma mantener los secretos fuera de la superficie pública y apagar el debug en producción, y previenes la mayoría de los incidentes reales de Laravel con estos tres.
Sigue leyendo
- Centro: seguridad por framework · seguridad de WordPress
- Secretos: mantén los secretos fuera de los directorios públicos · Caso: una exposición completa de .env
- Autorización: qué es IDOR · Práctica: el manual de respuesta a vulnerabilidades
FAQ
Q¿Es Laravel un framework seguro?
Laravel trae muchos valores por defecto seguros (escapado, autenticación) y es bastante sólido de fábrica. Pero 'valores por defecto seguros' y 'operación segura' son cosas distintas, y los incidentes reales no vienen del núcleo sino de la configuración y la operación. .env/secretos expuestos, debug dejado activado en producción y una autorización endeble son áreas que el framework no cubrirá por ti. No puedes depender solo de los valores por defecto — tienes que cerrar estos tres tú mismo.
Q¿Qué tiene de peligroso desplegar con APP_DEBUG=true?
Con debug activado, una página de error puede mostrar no solo una traza de pila sino secretos internos como variables de entorno e información de conexión. Un atacante puede provocar errores a propósito para extraerlos. En producción, pon siempre APP_DEBUG=false y cachea la configuración (caché de config) para que quede fijado, y detén que se muestren errores detallados hacia el exterior.
Q¿Por qué es peligroso 'si has iniciado sesión, puedes verlo'?
Eso es autenticación sin autorización. Incluso con sesión iniciada, si los datos no tienen alcance por usuario (por user_id, etc.), cambiar el ID en la URL puede revelar los datos de otra persona (IDOR). En Laravel, implementa comprobaciones de propiedad con Policy/Gate y declara $fillable para el Mass Assignment, para evitar que se sobrescriban campos no previstos.