Seguridad por framework

WordPress tiene la mayor cuota, así que es el mayor objetivo — pero los puntos de entrada son predecibles (vulnerabilidades de complementos/temas, actualizaciones omitidas, administradores débiles, paneles de administración expuestos). Esta es una referencia de trabajo: (1) una lista de verificación de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — actualizaciones automáticas, minimizar complementos/temas, administrador fuerte + 2FA, reducir la exposición del panel (xmlrpc/enumeración REST/edición de archivos), wp-config y secretos, permisos de archivos, HTTPS/copias de seguridad, actualidad de PHP/dependencias, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.

Los valores por defecto de Laravel son sólidos; los incidentes de producción vienen de la configuración y la operación. Esta es una referencia de trabajo: (1) un checklist de hardening ordenado por prioridad (P0–P2), (2) una tabla de valores por defecto peligrosos, (3) guía por área — secretos/APP_KEY, config de producción (APP_DEBUG/caché), autorización (Policy/Gate, Mass Assignment), inyección/salida (binding de Eloquent, Blade), sesiones/CSRF/cookies, subidas de archivos, HTTPS/cabeceras/limitación de tasa, CVE de dependencias de Composer, y (4) un checklist de autoverificación. Solo defensivo — sin pasos de ataque.

Los valores por defecto de Next.js son bastante seguros, pero los incidentes ocurren en la frontera servidor/cliente. Esta es una referencia de trabajo: (1) una lista de verificación de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — la frontera y las variables de entorno (NEXT_PUBLIC_), los CVE de dependencias (incluido RCE del núcleo), autorización + validación de entrada en Server Actions / Route Handlers, SSRF en las peticiones del lado servidor, cabeceras de seguridad/CSP, autenticación/sesión/cookies, limitación de tasa, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.

Express es minimalista — casi no protege nada por defecto, así que las defensas las añades tú. Esta es una referencia práctica: (1) una lista de comprobación de hardening ordenada por prioridad (P0–P2), (2) guía por área — cabeceras de seguridad (helmet) + desactivar x-powered-by, CVE de dependencias npm, validación de entrada e inyección (SQL/operador NoSQL), autenticación y autorización acotada al propietario, limitación de tasa y topes de tamaño, sesiones/cookies/CSRF, SSRF, manejo de errores en producción (sin exponer la pila), NODE_ENV, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.

Spring Boot es una base sólida, pero los incidentes vienen de las dependencias, la configuración y la autorización. Esta es una referencia práctica: (1) una lista de comprobación de hardening ordenada por prioridad (P0–P2), (2) guía por área — CVE de dependencias (de tipo Log4Shell, juzgados por la versión en ejecución), configuración de producción y secretos externalizados, autorización con Spring Security (denegación por defecto/seguridad a nivel de método/comprobaciones de propietario), reducción de la exposición de Actuator/gestión, deserialización insegura, inyección, cabeceras/CSRF/sesión, SSRF, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.

Django viene «con pilas incluidas» y valores por defecto seguros (ORM, CSRF, autoescapado, auth), pero los incidentes vienen de la configuración. Esta es una referencia de trabajo: (1) una lista de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — DEBUG=False + ALLOWED_HOSTS, externalizar SECRET_KEY, CVE de dependencias pip, configuración de seguridad de producción (SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE, etc.), autorización (alcance de propietario), inyección y salida (raw/extra, mark_safe), CSRF/sesiones/admin, SSRF/subidas, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.

Rails trae convenciones y valores por defecto seguros (protección CSRF, Strong Parameters, un ORM), pero los incidentes de producción vienen de la operación. Esta es una referencia de trabajo: (1) una lista de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — secretos y credentials (master key/secret_key_base), configuración de producción (force_ssl, sin exposición de excepciones), CVE de gems, Strong Parameters/Mass Assignment, autorización (Pundit, alcance de propietario), inyección y métodos peligrosos (interpolación en where/send/constantize), sesiones/cookies/CSRF, SSRF/subidas, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.

ASP.NET Core es una base madura y sólida, pero los incidentes vienen de la configuración. Esta es una referencia de trabajo: (1) una lista de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — no exponer errores detallados / la Developer Exception Page en producción, externalizar secretos (User Secrets/env/Key Vault), CVE de dependencias NuGet, autorización ([Authorize], denegación por defecto de reserva, basada en recurso/propietario), over-posting (DTOs/[Bind]), deserialización insegura (evitar BinaryFormatter), HTTPS/cabeceras/antiforgery, SSRF, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.