Seguridad por framework

WordPress tiene la mayor cuota, así que estadísticamente es el mayor objetivo. Los puntos de entrada son menos el núcleo que las vulnerabilidades de complementos/temas, las actualizaciones omitidas, los administradores débiles/reutilizados y las superficies de administración expuestas (wp-admin/xmlrpc/enumeración REST). Defensas: automatiza las actualizaciones del núcleo y complementos, elimina complementos/temas no usados, contraseña fuerte + 2FA para administradores, limita la exposición del panel y los intentos de inicio de sesión, detección de manipulación más copias de seguridad sin conexión.

Laravel trae valores por defecto bastante seguros, pero la mayoría de los incidentes vienen de la operación. Los tres grandes fallos: (1) .env o archivos de secretos alcanzables por URL desde el directorio público, (2) APP_DEBUG=true en producción exponiendo variables de entorno e info de conexión en la página de error, (3) autorización ausente (inicio de sesión = autenticación, pero sin autorización con alcance de propietario / Mass Assignment sobrescribiendo campos no previstos). Defensas: secretos fuera de public con permisos 600, debug apagado + caché de config en prod, autoriza con Policy/Gate, declara $fillable.

Next.js trae valores por defecto bastante seguros, pero los incidentes ocurren en la frontera servidor/cliente. Los tres grandes: (1) exposición de variables de entorno (mal uso de NEXT_PUBLIC_ o pasar secretos server-only al cliente), (2) autorización ausente en Server Actions / Route Handlers (autenticado pero sin delimitar por propietario) y (3) CVE conocidos de dependencias (incluido RCE en el núcleo del framework — juzga por la versión en ejecución y parchea rápido). Defensas: mantén los secretos en el servidor, cuida la frontera, autoriza en cada acción, monitorea los CVE de dependencias con una máquina.

Express es minimalista: casi no trae funciones de seguridad por defecto, así que las defensas son las que añade el desarrollador. Lo esencial: (1) cabeceras de seguridad (estilo helmet), (2) validación y saneamiento de la entrada, (3) autorización acotada al propietario, no solo autenticación, (4) limitación de tasa (fuerza bruta / DoS), (5) monitoreo de CVE de dependencias (npm) y parcheo rápido. Además, protección SSRF para las peticiones salientes de URL y secretos guardados en variables de entorno, fuera del código. La libertad de un framework mínimo viene con la responsabilidad de defender.

Spring (Spring Boot) es un básico empresarial. Tipos de incidente: (1) CVE conocidos de dependencias (un fallo de base ampliamente heredado como Log4Shell — juzga por la versión en ejecución y parchea rápido), (2) endpoints de gestión/diagnóstico como Actuator expuestos (fuga de información / operación), (3) autorización ausente en Spring Security (autenticado pero con comprobaciones de permiso débiles), (4) deserialización insegura. Defensas: monitorea con una máquina y parchea rápido los CVE de dependencias, blinda las superficies de Actuator/gestión, haz explícita la autorización, no deserialices datos no confiables.

Django viene 'con las pilas incluidas' y valores por defecto seguros (ORM, CSRF, autoescape de plantillas, auth) y es sólido si se configura correctamente. Pero los incidentes vienen de la configuración. Los tres grandes: (1) DEBUG=True en producción que expone ajustes, variables de entorno y secretos en la página de error, (2) una SECRET_KEY filtrada (la base de firmas/sesiones), (3) autorización débil (faltan comprobaciones de is_staff/permission). Además, SQLi por raw()/extra() o interpolación de cadenas, deserialización insegura (pickle), ALLOWED_HOSTS sin configurar y CVE de dependencias (pip). Defensas: DEBUG=False en prod, SECRET_KEY desde el entorno, autorización explícita.

Rails trae convenciones y valores por defecto seguros (protección CSRF, Strong Parameters, un ORM) y es sólido si se usa correctamente. Pero los incidentes vienen de la operación. Los tres grandes: (1) Strong Parameters demasiado permisivos que permiten Mass Assignment (sobrescribir is_admin, etc.), (2) autorización débil (login = autenticación, pero sin ámbito de propietario), (3) CVE conocidos de gems (dependencias). Además, SQLi por interpolación de cadenas en where, métodos dinámicos peligrosos (send/constantize) y fuga de credentials/secret_key_base. Defensas: ajustar el permit, hacer explícita la autorización, monitorear los CVE de gems.

ASP.NET Core es una base madura y sólida, pero los incidentes vienen de la configuración. Los tres grandes: (1) exponer errores detallados / la Developer Exception Page en producción (fuga de información interna), (2) secretos incrustados en appsettings.json (usa User Secrets / variables de entorno / Key Vault), (3) atributos de autorización ausentes ([Authorize]). Además, deserialización insegura (BinaryFormatter, etc.), over-posting en el model binding (limita con DTO/[Bind]) y CVE de dependencias NuGet. Defensas: oculta los errores detallados en prod, carga los secretos fuera de la configuración, haz explícita la autorización.