dependency management
4 artículos con esta etiqueta
Seguridad de Express (Node.js) — las defensas que añades tú mismo
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.
Seguridad de Next.js — Server Actions, variables de entorno y CVE de dependencias
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.
Seguridad de Ruby on Rails — Strong Parameters, autorización y CVE de gems
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.
Seguridad de Spring Boot — CVE de dependencias, exposición de Actuator y autorización
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.