Por framework
Seguridad por framework — defensas específicas para la tecnología que usas
Un centro de seguridad por framework — los peligros por defecto, los puntos débiles que más se explotan y los pasos de hardening — para WordPress, Laravel, Next.js, Spring y más. Los tipos de amenaza son compartidos; lo que cambia son los fallos por defecto de cada framework. Defensivo, sin pasos de ataque.
«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. La base defensiva también es compartida.
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.
Los "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 los proyecta sobre «cómo se manifiesta en esa tecnología».
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
Laravel
Next.js
Java / Spring
Express / Rails / Django / ASP.NET Core
La visión de este sitio: el framework es la herramienta, el incidente es la operación
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 es magia especial: 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 recuperables. Cada capítulo de framework es solo esa base, expresada en las propias palabras de esa tecnología.
Blinda primero la base compartida
Antes de meterte en un capítulo de framework, es eficiente afianzar primero lo que funciona en todas las tecnologías.
- Inicio: la lista de comprobación de la base de seguridad (las llaves del reino, 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
Sigue leyendo
- Guías: seguridad de WordPress · seguridad de Laravel
- Base: 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 cerrar los fallos 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 (agujeros desconocidos) y más mala configuración por parte de desarrolladores que aún los están aprendiendo. Los frameworks más antiguos están curtidos en batalla, 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 blinda la base compartida por 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 cierra uno por uno sus fallos por defecto específicos de la tecnología (por ejemplo, la gestión de complementos en WordPress, el APP_DEBUG/autorización de Laravel).