framework
9 artículos con esta etiqueta
Seguridad en Django — una referencia de endurecimiento para producción
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.
Seguridad por framework — defensas específicas para la tecnología que usas
Sea cual sea el framework que uses, los *tipos* de debilidad que atacan los agresores son en gran medida los mismos (control de acceso, secretos, inyección, CVE de dependencias, mala configuración). Lo que cambia son los 'valores por defecto peligrosos' y 'el punto más atacado' de cada framework. Este sitio ofrece, por framework, los fallos por defecto y los pasos de hardening. Empieza por el capítulo de la tecnología que de verdad usas.
Seguridad de Laravel — una referencia de hardening para producción
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.
Seguridad de Next.js — una referencia de endurecimiento para producción
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.
Seguridad de Spring Boot — una referencia de hardening para producción
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.
Seguridad de WordPress — una referencia de endurecimiento para producción
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.
Seguridad en ASP.NET Core — una referencia de endurecimiento para producción
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.
Seguridad de Express (Node.js) — una referencia de hardening para producción
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.
Seguridad en Ruby on Rails — una referencia de endurecimiento para producción
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.