Por framework

#framework #getting started #hardening #misconfiguration

Seguridad por framework — defensas específicas para la tecnología que usas

Guías de seguridad para WordPress, Laravel, Next.js, Spring y más: valores por defecto peligrosos, puntos más atacados y pasos de hardening.

Publicado 2026-07-02 Actualizado 2026-10-06 10 min de lectura

En esta página

«Seguridad de Laravel», «hardening de WordPress» — cuando buscamos, buscamos respuestas por tecnología. Esta página es el punto de entrada a la defensa por framework (sin pasos de ataque).

Compartido (igual en todos los frameworks)

control de acceso, secretos, inyección, CVE de dependencias, mala configuración. Las defensas básicas también son compartidas.

Específico del framework (cada capítulo)

los «valores por defecto peligrosos» y «el punto más atacado». Esta es la única parte que cambia según la tecnología.

Sea cual sea el framework, los 'tipos de debilidad' son compartidos — solo cambian los valores por defecto peligrosos y el punto atacado.

Tipos de debilidad compartidos por todos los frameworks

Primero el panorama general. Estos tipos se atacan una y otra vez sin importar la tecnología; cada capítulo de framework explica cómo se manifiestan en esa tecnología.

Control de acceso

autenticación ≠ autorización, IDOR, paneles de administración expuestos (la mayor fuente de incidentes)

Secretos

exposición de .env/claves, almacenamiento en texto plano, subidos a Git

Inyección

SQLi, XSS, inyección de plantilla/comando

CVE de dependencias / mala config

fallos conocidos sin parchear, debug en producción, valores por defecto peligrosos

Guías por framework

Lee el capítulo de tu tecnología. Cada uno va «peligros por defecto → punto más atacado → pasos de hardening».

WordPress

Su mayor cuota lo convierte en el mayor objetivo. Las principales vías de entrada: vulnerabilidades de complementos/temas, actualizaciones omitidas, administradores débiles, paneles de administración expuestos. → seguridad de WordPress

Laravel

Los valores por defecto son sólidos, pero los incidentes vienen de la operación. Los tres grandes: exposición de .env, APP_DEBUG=true en producción, autorización ausente (autenticación ≠ autorización / Mass Assignment). → seguridad de Laravel

Next.js

La frontera servidor/cliente, la exposición de variables de entorno y los CVE de dependencias son los puntos clave. → seguridad de Next.js

Java / Spring

CVE de dependencias (tipo Log4Shell), exposición de Actuator, configuración de autorización y deserialización son los puntos clave. → seguridad de Spring Boot

Express / Rails / Django / ASP.NET Core

En frameworks minimalistas o de valores por defecto seguros, los incidentes vienen de la operación y la configuración: cabeceras, validación de entrada, autorización, secretos y CVE de dependencias. → Express · Ruby on Rails · Django · ASP.NET Core

Ajustes que hay que revisar primero en producción (tabla rápida por framework)

En cualquier framework, revisa primero dos cosas: si producción muestra errores detallados y dónde viven tus secretos. Los nombres de los ajustes cambian, así que busca tu fila más abajo. Los nombres se han contrastado con la documentación oficial actual de cada proyecto (versión en la última columna).

Framework	Desactivar las páginas de error detalladas	Dónde viven los secretos, y la trampa	Ajuste que se suele olvidar	Documentación revisada
WordPress	`WP_DEBUG` a `false` en `wp-config.php` (false por defecto)	Credenciales de la BD en `wp-config.php`; nunca dejes copias en directorios públicos	`DISALLOW_FILE_EDIT` para bloquear la edición de archivos desde el panel; borra los complementos que no uses	Advanced Administration Handbook
Laravel	`APP_DEBUG=false` en `.env`	Nunca subas `.env` al repositorio (un `.env.encrypted` cifrado sí vale)	Tras `config:cache`, `env()` fuera de los archivos de configuración no devuelve nada	13.x
Next.js	Ejecuta `next build` y luego `next start`; nunca expongas el servidor de desarrollo	Las variables `NEXT_PUBLIC_` se incrustan en el JavaScript del navegador	Un secreto con el prefijo `NEXT_PUBLIC_`	16.x
Spring Boot	Deja las trazas de la pila fuera de las respuestas de error (mantén el valor por defecto)	Pasa los valores por variables de entorno, no en configuración escrita en el código	Actuator solo expone `health` por HTTP por defecto; nunca pongas `management.endpoints.web.exposure.include=*`	4.1
Django	`DEBUG = False`	Carga `SECRET_KEY` desde una variable de entorno o un archivo; mantenla fuera del control de versiones	Configura `ALLOWED_HOSTS`; ejecuta `manage.py check --deploy`	6.1
Ruby on Rails	Usa la configuración del entorno de producción (`config/environments/production.rb`)	`config/credentials.yml.enc` más `config/master.key`; nunca subas master.key	`config.force_ssl = true` para forzar HTTPS	8.1
Express	`NODE_ENV=production` quita las trazas de la pila de la respuesta de error por defecto	Pásalos por variables de entorno, no en el código	`helmet` para cabeceras seguras; `app.disable('x-powered-by')`	Guía oficial actual
ASP.NET Core	La Developer Exception Page solo está activa en el entorno Development (valor por defecto de la plantilla actual)	Los user secrets son para desarrollo; en producción usa variables de entorno o un almacén de claves	Nunca ejecutes producción con `ASPNETCORE_ENVIRONMENT` en Development	10.0

Casos reales: la mayoría de los incidentes vinieron de actualizaciones omitidas y ajustes de producción, no de fallos del núcleo

El patrón que destaca no es el fallo del framework en sí, sino una corrección disponible que no se aplicó, o un ajuste de desarrollo que se quedó en producción.

Equifax (2017): la corrección del fallo de Apache Struts (CVE-2017-5638) se publicó el mismo día en que se divulgó, pero no se aplicó a un sistema público, y se filtraron datos personales de unos 147 millones de personas (→ la filtración de Equifax).
Log4Shell (2021): un fallo en una librería de registro de Java. Muchas organizaciones la tenían incorporada a través de otros componentes y no podían saber si la usaban (→ Log4Shell).
Casos de agentes de IA (2026): cuando agentes de IA de investigación llegaron a sitios web reales, se leyeron credenciales desde una página de debug expuesta, y los sitios no se dieron cuenta (→ AI agents reaching real websites, en inglés).

En el OWASP Top 10 (2025), el número uno es el control de acceso roto, el número dos la mala configuración de seguridad y el número tres los fallos en la cadena de suministro de software (problemas en los componentes de los que dependes). Todos ocurren en cualquier framework.

Cómo comprobar tu propio sitio

Haz estas comprobaciones solo en sitios que gestionas tú.

Abre una URL que no existe y mira la página de error

Abre cualquier URL inventada de tu sitio y confirma que no aparecen fragmentos de código fuente, rutas de archivos ni valores de configuración. Si aparecen, corrige el ajuste de «desactivar las páginas de error detalladas» de la tabla anterior.

Usa los comandos de comprobación del propio framework

Django tiene python manage.py check --deploy; Laravel muestra el modo debug con php artisan about --only=environment. En Spring Boot, revisa management.endpoints.web.exposure.include en tu configuración.

Analiza las dependencias y lo que se ve desde fuera

Para las vulnerabilidades conocidas en dependencias, usa npm audit para npm, composer audit para Composer u osv-scanner para todo (desde el navegador: el analizador de vulnerabilidades de dependencias). Para lo que pueden ver los de fuera, la comprobación de cabeceras de seguridad muestra las cabeceras que faltan, y la auditoría de seguridad completa del sitio revisa de una vez la exposición de .env y .git, los certificados y los atributos de las cookies.

Errores habituales y cómo corregirlos

Error habitual	Qué pasa	Corrección
Poner el prefijo `NEXT_PUBLIC_` a una clave de API secreta	La clave se incrusta en el JavaScript del navegador, donde cualquiera puede leerla	Quita el prefijo, úsala solo en el servidor y revoca la clave filtrada en el emisor
Exponer todos los endpoints de monitorización (p. ej. Spring Boot Actuator)	Los valores de configuración y el contenido de la memoria se pueden leer desde fuera	Expón solo `health` y similares; deja el resto tras autenticación
Desactivar los complementos que no usas pero dejarlos instalados	Los archivos siguen en el servidor y dejan de recibir actualizaciones	Borra lo que no uses
Leer un aviso de actualización sin confirmar que se ha aplicado	El agujero sigue abierto aunque exista corrección (el patrón de Equifax)	Comprueba la versión tras actualizar y analiza las dependencias de forma periódica

La visión de este sitio: los incidentes vienen de cómo se opera un framework, no del framework en sí

Discutir «este framework es seguro/peligroso» rara vez ayuda. La mayoría de los incidentes reales no vienen de un fallo del núcleo sino del uso — actualizaciones omitidas, secretos expuestos, autorización ausente, valores por defecto peligrosos. Este sitio funciona sobre Next.js, y nuestra defensa principal no tiene nada de especial: monitorear los CVE de dependencias, mantener los secretos fuera del código y de los directorios públicos, autenticación fuerte, copias de seguridad recuperables. Cada capítulo de framework aplica esa base a esa tecnología concreta.

Primero, cubre lo básico compartido

Antes de meterte en un capítulo de framework, es eficiente establecer primero lo que funciona en todas las tecnologías.

Inicio: la lista de comprobación de la base de seguridad (cuentas de administración, secretos, parcheo, detección, recuperación)
Práctica: el manual de respuesta a vulnerabilidades · monitorear los CVE de dependencias (osv-scanner)
Secretos: mantén los secretos fuera de los directorios públicos

Fuentes

WordPress Advanced Administration Handbook, "Hardening WordPress" y "Debugging in WordPress" — developer.wordpress.org
Laravel 13.x, "Configuration" (Environment File Security / Debug Mode) — laravel.com
Next.js, "How to use environment variables in Next.js" (16.x) — nextjs.org
Spring Boot 4.1, "Endpoints" (exposición de Actuator) — docs.spring.io
Django 6.1, "Deployment checklist" — docs.djangoproject.com
Ruby on Rails Guides, "Securing Rails Applications" (8.1) — guides.rubyonrails.org
Express, "Production Best Practices: Security" y "Error Handling" — expressjs.com
Microsoft Learn, "Handle errors in ASP.NET Core" (10.0) — learn.microsoft.com
OWASP Top 10:2025 — top10.owasp.org

Sigue leyendo

Guías: seguridad de WordPress · seguridad de Laravel
Lo básico: la lista de comprobación de la base de seguridad (compartida por todos los frameworks)
Glosario: qué es un CVE (la unidad para rastrear los fallos conocidos de un framework)

FAQ

Q¿Cuál es el framework más peligroso?

Menos que un 'framework peligroso', el problema es el 'uso peligroso'. Dicho esto, desde la perspectiva de un atacante, 'más instalaciones = más vale la pena atacarlo', así que la plataforma con mayor cuota del mundo — WordPress y sus complementos — es estadísticamente la más atacada. Aun así, en cualquier framework, la mayoría de los incidentes no vienen de un fallo del núcleo sino de la operación: actualizaciones omitidas, secretos expuestos, autorización ausente y valores por defecto peligrosos. Por eso corregir los valores por defecto peligrosos de tu propia tecnología es más útil que clasificar frameworks.

Q¿Es más seguro un framework más nuevo?

No necesariamente. Los frameworks más nuevos suelen traer valores por defecto más seguros, pero también tienen un historial más corto (fallos aún no descubiertos) y más mala configuración por parte de desarrolladores que aún los están aprendiendo. Los frameworks más antiguos están maduros y bien probados, pero sufren de versiones mayores obsoletas y sin parchear (EOL) y de una gran superficie de complementos y dependencias. Al final, la operación que funciona es: sigue las versiones, entiende los valores por defecto peligrosos y defiende por capas.

Q¿Por dónde debería empezar?

Primero establece lo básico, común a todos los frameworks (monitorea los CVE de dependencias, mantén los secretos fuera del código y de los directorios públicos, autenticación fuerte, copias de seguridad). Luego abre el capítulo del framework que de verdad usas y corrige uno por uno sus valores por defecto peligrosos específicos de la tecnología (por ejemplo, la gestión de complementos en WordPress, el APP_DEBUG/autorización de Laravel).

Q¿Qué riesgo tiene dejar activado el modo debug en producción?

Cuando se produce un error, se muestran en pantalla partes de tu código fuente, valores de configuración y las librerías que usas. La documentación de Laravel indica que APP_DEBUG=true en producción expone a los usuarios valores de configuración sensibles, y Django dice que nunca debes activar debug en producción. En los casos de agentes de IA divulgados en 2026, se leyeron credenciales desde una página de debug expuesta. Desactívalo siempre en producción y después abre una URL que no existe para confirmar que no aparece ningún error detallado.

Q¿Cómo compruebo si mi framework tiene una vulnerabilidad conocida?

Comprueba la versión que ejecutas y después analiza tus dependencias en conjunto. Usa npm audit para npm, composer audit para Composer de PHP u osv-scanner para cualquier lenguaje; la herramienta de análisis de vulnerabilidades de dependencias de este sitio también sirve. Las vulnerabilidades con explotación confirmada entran en el catálogo KEV de la CISA de EE. UU., así que actualiza primero todo lo que esté en KEV.

Q¿Puedo poner una clave de API en una variable de entorno NEXT_PUBLIC_ de Next.js?

No. Como explica la documentación de Next.js, las variables con el prefijo NEXT_PUBLIC_ se incrustan en el momento de la compilación en el JavaScript que se envía al navegador, donde cualquiera puede leerlas. Mantén las claves secretas sin prefijo y solo en el servidor, y canaliza lo que necesite el navegador a través de la API de tu propio servidor.