# Security > Seguridad aplicada: OWASP, autenticación/autorización, secretos, validación, defensa en profundidad. - Skill: `julianramirezreyes/security` (Agent Skill) - Install (CLI): `npx skillmds@latest add julianramirezreyes/security` - Raw SKILL.md: https://api.skillmd.com/api/skills/julianramirezreyes/security/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: julianramirezreyes (https://skillmd.com/u/julianramirezreyes) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/julianramirezreyes/security --- # Seguridad Aplicada > **Cuándo usar:** léela ANTES de tocar cualquier cosa sensible: flujos de autenticación o autorización, manejo de datos de usuario o PII, endpoints públicos o expuestos a internet, formularios y parámetros que reciben entrada externa, consultas a base de datos con datos del usuario, manejo de secretos/credenciales/tokens, cookies y sesiones, subida de archivos, integraciones con terceros, o cualquier código que decida "¿este usuario puede hacer esto?". Si dudas de si aplica, aplica. La seguridad no es una feature que se agrega al final: es una propiedad transversal del diseño. Un sistema seguro no depende de que "nadie encuentre el fallo", sino de que el fallo, aunque exista, no comprometa todo. Este skill tiene enfoque **defensivo**: proteger el sistema, no atacarlo. El objetivo es que entiendas el PORQUÉ de cada regla, porque una regla memorizada sin entender se rompe en el primer caso que no la contempla. --- ## 1. Principios fundamentales Estos cinco principios son la base. Cada regla concreta más abajo es una consecuencia de alguno de ellos. - **Defensa en profundidad (defense in depth):** nunca dependas de una sola barrera. Si el WAF falla, la validación de entrada debe atrapar el ataque; si esa falla, la consulta parametrizada; si esa falla, los permisos mínimos de la BD limitan el daño. Capas independientes. Un atacante debe romper TODAS, no una. - **Mínimo privilegio (least privilege):** cada componente, usuario, token o proceso recibe solo los permisos que necesita para su tarea, ni uno más. El servicio que lee reportes no necesita `DROP TABLE`. El token de un widget de frontend no necesita scope de admin. Menos privilegio = menos superficie de daño cuando algo se compromete. - **Secure by default:** el estado por defecto debe ser el seguro. Un endpoint nuevo debe estar cerrado hasta que explícitamente lo abras, no abierto hasta que recuerdes cerrarlo. Un permiso ausente se interpreta como "denegar", no como "permitir". La configuración de fábrica no debe requerir "endurecerla" para ser segura. - **No confiar en la entrada (never trust input):** TODO dato que cruza una frontera de confianza es hostil hasta que se demuestre lo contrario: parámetros HTTP, headers, cookies, cuerpos JSON, archivos subidos, respuestas de APIs de terceros, incluso datos que vienen de tu propia BD si originalmente los puso un usuario. La validación ocurre en el **servidor**, siempre. El cliente valida por UX, no por seguridad. - **Fail securely (fallar de forma segura):** cuando algo sale mal, el sistema debe caer hacia el estado seguro, no hacia el abierto. Si la verificación de permisos lanza una excepción, el resultado es DENEGAR, no PERMITIR. Un error nunca debe convertirse accidentalmente en un bypass. Compara: `if (tienePermiso()) permitir()` deja pasar si `tienePermiso()` explota y alguien lo captura mal; el diseño correcto deniega por defecto y solo permite en el camino explícitamente autorizado. --- ## 2. Reglas de oro | Haz | Evita | | --- | --- | | Validar y autorizar SIEMPRE en el servidor | Confiar en validaciones o checks del cliente | | Consultas parametrizadas / ORM con bindings | Concatenar entrada del usuario en SQL/comandos | | Hashear contraseñas con bcrypt / argon2 / scrypt | MD5, SHA-1, SHA-256 "a secas" o texto plano | | Codificar la salida según el contexto (HTML, JS, URL) | Insertar datos del usuario crudos en el DOM | | Secretos en gestor de secretos / variables de entorno | Secretos hardcodeados o commiteados al repo | | Allowlist (lista de lo permitido) | Denylist (lista de lo prohibido) | | HTTPS/TLS en todo, HSTS activo | HTTP plano, TLS opcional o downgradeable | | Verificar autorización por objeto en cada acceso | Asumir que "solo la UI muestra sus datos" | | Mensajes de error genéricos al cliente | Devolver stack traces, versiones o SQL al cliente | | Rate limiting en auth y endpoints costosos | Login/reset sin límite de intentos | | Rotar y revocar credenciales y tokens | Tokens eternos sin expiración ni revocación | | Dependencias actualizadas y escaneadas | Librerías con CVEs conocidos "porque funciona" | --- ## 3. OWASP Top 10 (referencia 2021, vigente) El estándar de facto para priorizar riesgos en aplicaciones web. Conócelo de memoria a nivel de qué es y cómo se mitiga. 1. **A01 – Broken Access Control (control de acceso roto):** el usuario accede a datos o acciones que no le corresponden (ver el pedido de otro, escalar a admin). *Mitigar:* denegar por defecto, verificar autorización por objeto en el servidor en CADA request, no exponer IDs adivinables sin check de propiedad. Ver §8. 2. **A02 – Cryptographic Failures (fallos criptográficos):** datos sensibles sin cifrar o con cripto débil (contraseñas en SHA plano, TLS opcional, PII en claro). *Mitigar:* TLS obligatorio, cifrado en reposo, algoritmos actuales, hashing lento para contraseñas. Ver §7 y §14. 3. **A03 – Injection (inyección):** SQL, NoSQL, comandos de SO, LDAP donde entrada del usuario se interpreta como código. *Mitigar:* consultas parametrizadas, ORM, validación por allowlist, nunca concatenar. Ver §4. 4. **A04 – Insecure Design (diseño inseguro):** el fallo está en la arquitectura, no en un bug puntual (flujo de recuperación de cuenta sin verificación, ausencia de límites de negocio). *Mitigar:* threat modeling, patrones seguros desde el diseño, historias de abuso además de historias de usuario. 5. **A05 – Security Misconfiguration (configuración insegura):** defaults inseguros, features de debug en producción, permisos abiertos, cabeceras faltantes. *Mitigar:* hardening por defecto, deshabilitar lo no usado, cabeceras de seguridad, revisar config por entorno. Ver §13. 6. **A06 – Vulnerable and Outdated Components (componentes vulnerables):** dependencias con CVEs conocidos. *Mitigar:* inventario de dependencias, escaneo continuo, actualizar, lockfiles. Ver §15. 7. **A07 – Identification and Authentication Failures (fallos de autenticación):** login débil, sesiones mal gestionadas, credenciales por defecto, sin MFA. *Mitigar:* hashing fuerte, MFA, gestión de sesión robusta, rate limiting. Ver §6 y §9. 8. **A08 – Software and Data Integrity Failures (fallos de integridad):** deserialización insegura, actualizaciones o dependencias sin verificar firma, CI/CD comprometido. *Mitigar:* verificar integridad/firmas, no deserializar datos no confiables, proteger el pipeline (supply chain). Ver §15. 9. **A09 – Security Logging and Monitoring Failures (fallos de logging y monitoreo):** ataques que pasan inadvertidos por falta de registro o alertas. *Mitigar:* logging de eventos de seguridad, monitoreo y alertas, sin loggear secretos. Ver §16. 10. **A10 – Server-Side Request Forgery (SSRF):** el servidor hace peticiones a URLs controladas por el atacante (acceso a metadata interna, red interna). *Mitigar:* allowlist de destinos, bloquear rangos internos/loopback, no reenviar URLs crudas del usuario. --- ## 4. Inyección (SQL / NoSQL / comandos) La inyección ocurre cuando datos se interpretan como código. La causa raíz es **mezclar datos y código en la misma cadena**. La solución no es "escapar mejor": es **separar estructuralmente** datos de instrucciones. **Regla absoluta: nunca concatenes entrada del usuario en una consulta o comando.** ```sql -- ❌ VULNERABLE: la entrada se convierte en código query = "SELECT * FROM users WHERE email = '" + email + "'" -- entrada: ' OR '1'='1 → devuelve todos los usuarios -- ✅ SEGURO: consulta parametrizada, el driver separa datos de código query = "SELECT * FROM users WHERE email = ?" db.execute(query, [email]) ``` - **SQL:** usa consultas parametrizadas / prepared statements SIEMPRE, o un ORM que use bindings por debajo. El placeholder (`?`, `$1`, `:email`) garantiza que el valor jamás se interprete como estructura. - **NoSQL (p. ej. MongoDB):** también es inyectable. Un `{ "$gt": "" }` inyectado en un campo de contraseña puede saltarse el login. Valida tipos, rechaza operadores en entrada, usa el driver correctamente. - **Comandos de SO:** evita invocar shell con entrada del usuario. Si es inevitable, usa APIs que reciban argumentos como array (no una cadena de shell) y valida contra allowlist. Nunca `exec("convert " + filename)`. - **Cuando la parametrización no cubre** (nombres de tabla/columna dinámicos, `ORDER BY`): usa **allowlist** — compara la entrada contra un conjunto fijo de valores válidos, nunca la insertes directa. Enlace: al diseñar el acceso a datos, coordina con **database-design** para modelos y permisos de BD con mínimo privilegio. --- ## 5. Cross-Site Scripting (XSS) XSS ejecuta JavaScript del atacante en el navegador de la víctima. Causa raíz: **datos del usuario tratados como marcado/código en la salida.** La defensa central es **codificar la salida según el contexto**. - **Reflejado:** la entrada vuelve inmediatamente en la respuesta (búsqueda que repite el término sin codificar). - **Almacenado:** la carga se guarda (comentario, perfil) y ataca a todos los que lo ven. El más peligroso. - **DOM-based:** JS del propio sitio escribe entrada no confiable en el DOM (`innerHTML`, `document.write`). Mitigaciones, en capas: - **Codificación de salida contextual:** codifica según DÓNDE se inserta el dato — HTML body, atributo, dentro de `