Preguntas de entrevista de Application Security Engineer

No. La validación en el cliente es una pura comodidad de UX — un atacante puede desactivar JavaScript, editar la petición en el navegador o Burp, o llamar a tu API directamente con curl, saltándosela por completo. Los controles de seguridad (validación, autorización, saneamiento) deben imponerse en el servidor, el único lugar que controlas. El error es tratar el navegador como una frontera de confianza; no lo es, porque el cliente corre en la máquina del atacante. Los controles de cliente sirven para dar respuesta rápida, nunca para la seguridad.

No se descifra — los hashes criptográficos son funciones unidireccionales sin inversa. «Crackear» un hash significa adivinar entradas candidatas, hashear cada una y comparar (diccionario, fuerza bruta, rainbow tables), que es justo por lo que se usan hashes lentos y salados para las contraseñas. No hay ninguna clave que «descifre» un hash. Si algo se puede descifrar, fue cifrado, no hasheado — y Base64 es codificación reversible, no hash.

No. Borrar la cookie solo quita la credencial de tu navegador — el registro de sesión (o un JWT aún válido) en el servidor suele seguir siendo utilizable hasta que expire o se invalide de forma explícita. Un atacante que ya capturó el token puede seguir usándolo. El error trata la cookie como la sesión misma; es solo un puntero al estado del servidor. El cierre real debe invalidar la sesión en el servidor, o revocar y dar un TTL corto al token.

No. TLS/HTTPS asegura los datos en tránsito entre cliente y servidor; una vez recibidos, la aplicación los descifra y los maneja en texto plano, y luego se almacenan según cómo esté configurada la base de datos. Proteger los datos en reposo es un asunto aparte — cifrado de disco/columna, un KMS y control de acceso. Confundir «usamos HTTPS» con «nuestros datos almacenados están cifrados» es una idea errónea común y peligrosa.

No. HTTPS cifra el canal para que los atacantes no puedan leer ni manipular el tráfico en tránsito, pero la entrada maliciosa llega, se descifra y la procesa tu aplicación igual que antes. La inyección SQL y el XSS son fallos de la capa de aplicación que se corrigen con consultas parametrizadas y codificación de salida, no con cifrado de transporte. El error supone que el cifrado sanea el contenido — no lo hace; el atacante simplemente envía la carga por la conexión HTTPS.

No. POST simplemente lleva los parámetros en el cuerpo de la petición en vez de en la URL; ese cuerpo va en texto plano y es totalmente visible para quien pueda ver el tráfico, salvo que se use HTTPS. POST es preferible para acciones que cambian el estado y mantiene los parámetros fuera de URL, registros e historial, pero no aporta confidencialidad por sí mismo. El error confunde «no está en la URL» con «cifrado» — solo TLS cifra los datos de cualquiera de los dos métodos en tránsito.

No. Una sal es un valor aleatorio único almacenado justo al lado del hash; su función es lograr que contraseñas idénticas produzcan hashes distintos y anular las rainbow tables precalculadas — no permanecer en secreto. Es normal que un atacante que roba la base obtenga también las sales. Lo que protege de verdad las contraseñas es un hash lento y salado (bcrypt, scrypt, Argon2). Una «pimienta» secreta opcional y separada es un concepto diferente.

La autonomía sin límites más el acceso a herramientas es la «agencia excesiva» de OWASP LLM: un modelo manipulado o equivocado puede tomar acciones destructivas. Acótalo con herramientas de mínimo privilegio, exige confirmación humana para operaciones irreversibles, y mantén los permisos estrechos y auditados. Confiar en él o darle admin amplía el radio de impacto, y ocultar un botón en la interfaz no hace nada respecto a la capacidad subyacente del modelo de invocar la acción.

El contenido no confiable que el modelo ingiere puede llevar instrucciones — es la inyección de prompts indirecta. No puedes evitar del todo que el modelo sea influido, así que aísla el contenido recuperado como dato, acota qué herramientas/permisos tiene el agente, exige confirmación para acciones sensibles, y evita darle secretos que pudiera ser coaccionado a filtrar. Suponer que el modelo simplemente ignorará las instrucciones inyectadas es exactamente el modo de fallo que se explota.

Un modelo de terceros es una dependencia de cadena de suministro: verifica que provenga de una fuente de confianza con sumas de verificación/firmas coincidentes, que su licencia permita tu uso, y que el formato de archivo no ejecute código arbitrario al cargarse (prefiere serialización segura frente a formatos tipo pickle). «Se carga» y «velocidad de descarga» no dicen nada sobre la confianza, y suponer que los modelos públicos son seguros ignora los riesgos reales de envenenamiento y deserialización.

Esto es el «manejo inadecuado de la salida» de OWASP LLM: la salida del modelo, influida por la entrada del usuario, puede convertirse en inyección de comandos al pasarla a un shell o a eval. Trátala como no confiable — asigna intenciones a una pequeña lista blanca de acciones parametrizadas, valida estrictamente y ejecuta en un entorno aislado en vez de lanzar cadenas generadas en bruto. Confiar en la salida, subir el límite de tokens o solo registrar no detiene la inyección.

Enviar PII de clientes a una API externa la expone al procesamiento y la retención de un tercero y puede incumplir obligaciones de privacidad. Minimiza y redacta lo que se envía, confirma los términos de uso/retención del proveedor y un acuerdo de procesamiento de datos (o garantías de no entrenamiento), o pasa a un despliegue privado para datos sensibles. La longitud de la clave es irrelevante, y enviar más PII aumenta la exposición.

Si la recuperación extrae cualquier documento indexado sin importar quién pregunta, el modelo expondrá fielmente datos que el usuario no debería ver — es un fallo de autorización, no una alucinación. Aplica los permisos del usuario a nivel de documento en el momento de la recuperación, para que solo los fragmentos autorizados entren en el contexto. Un prompt de sistema más largo es evitable y no implementa control de acceso, la temperatura no tiene relación, y otro modelo tiene la misma brecha.

Entrenar con datos de usuario no verificados permite a un atacante envenenar el modelo — implantando puertas traseras, disparadores o comportamiento sesgado que aflora más tarde. Contrólalo con verificación y filtrado de datos, seguimiento de procedencia, detección de anomalías en el conjunto de datos y evaluación del comportamiento del modelo tras el entrenamiento. «Más datos es mejor» ignora la integridad, y la verdadera preocupación es el envenenamiento, no la velocidad ni el espacio en disco.

El almacenamiento de contraseñas necesita un hash deliberadamente lento, salado y con alto coste de memoria — bcrypt, scrypt o Argon2 — para que crackear hashes robados sea costoso y las rainbow tables no apliquen. Un hash rápido como SHA-256 se fuerza por fuerza bruta trivialmente a gran escala; el cifrado reversible implica que una sola compromisión de clave expone todas las contraseñas a la vez; y el texto plano es indefendible por muy cerrada que esté la base de datos. Elija Argon2id (o bcrypt) con un factor de coste ajustado y un salt único por usuario.

Un open redirect en un flujo de autenticación permite al atacante crear un enlace de login de apariencia fiable que, tras la autenticación, envía al usuario — y potencialmente un código de autorización o token — a un dominio controlado por el atacante, permitiendo el secuestro de cuenta y un phishing convincente. Corríjalo allow-listando estrictamente los redirect URI exactos del lado del servidor y rechazando cualquier otro. No es cosmético ni un problema de rendimiento, y HTTPS no ayuda porque el destino del atacante también puede ser un sitio HTTPS válido.

Si el navegador adjunta automáticamente la cookie de sesión, una página maliciosa puede desencadenar la transferencia en nombre de la víctima — es Cross-Site Request Forgery (CSRF). Proteja las peticiones que cambian de estado con tokens anti-CSRF y cookies SameSite, y verifique la cabecera Origin/Referer. La cookie prueba la identidad pero no la intención, un CAPTCHA de inicio de sesión no protege una acción ya autenticada, y HTTPS protege la confidencialidad del transporte, no la falsificación de peticiones.

Si un atacante puede subir un archivo ejecutable del lado del servidor (o HTML/SVG) a un directorio servido, puede lograr ejecución remota de código o XSS almacenado. Valide el tipo de contenido real, almacene los archivos fuera de la raíz web o en un almacén no ejecutable, aleatorice los nombres y sírvalos de modo que no puedan ejecutarse ni interpretarse como marcado. Las cargas de página más lentas y el uso de disco son problemas operativos, no el riesgo de seguridad explotado aquí.

Recuperar del lado del servidor URLs controladas por el atacante es Server-Side Request Forgery (SSRF): permite alcanzar servicios internos o el endpoint de metadatos del cloud para robar credenciales. Mitíguelo con una allow-list de hosts y esquemas permitidos, bloqueando rangos privados y link-local (revisando de nuevo tras cada redirección) y endureciendo el acceso a metadatos con IMDSv2. Decir que no hay riesgo ignora el acceso que concede la petición, y un spinner de carga o una caché no cambian nada sobre dónde puede conectarse el servidor.

Es control de acceso roto (IDOR): el servidor no comprueba que el usuario autenticado pueda acceder al objeto solicitado. La corrección es una autorización por objeto aplicada en el servidor en cada solicitud. Sanear el número no establece la propiedad. Cifrar u ofuscar el ID es oscuridad y sigue siendo adivinable, filtrable o reproducible. El método HTTP es irrelevante para la autorización. Verifica siempre el derecho del llamante sobre el objeto concreto antes de devolverlo.

`alg: none` permite a cualquiera fabricar un token sin firmar de apariencia válida y suplantar a cualquier usuario — una elusión total de autenticación, no un hallazgo menor. Corrígelo permitiendo en el servidor una lista blanca de los algoritmos esperados y verificando siempre la firma con la clave correcta; nunca confíes en el encabezado alg del propio token para elegir el método de verificación. Una expiración más larga o cambiar dónde se guarda el token no hace nada contra tokens falsificados y sin firmar. Es crítico y explotable, así que documentar no es una corrección.

La inyección de prompts no se resuelve por completo con más texto; asume que el modelo puede ser subvertido y restringe lo que se le permite HACER. Da a las herramientas el mínimo privilegio, condiciona las acciones de alto impacto a confirmación humana, y valida o aísla las llamadas a herramientas antes de actuar (OWASP LLM «agencia excesiva» y «gestión inadecuada de salidas»). Suplicar en el prompt del sistema es evitable. Una temperatura mayor solo añade aleatoriedad, y solo registrar deja constancia del daño sin impedir la acción inyectada.

Es un fallo de asignación masiva (over-posting): el servidor mapea a ciegas el JSON del cliente sobre campos sensibles del modelo. Corrígelo vinculando solo una lista blanca explícita de campos permitidos (DTO / strong params) para que atributos privilegiados como isAdmin no los pueda establecer el cliente. Ocultar el campo en el frontend y añadir validación en el cliente se evitan ambos con una solicitud cruda. Renombrar isAdmin es oscuridad, fácilmente descubierta. Controla qué campos se vinculan, en el servidor.

Las consultas parametrizadas son la verdadera corrección: separan el código de los datos, de modo que la entrada del usuario siempre se trata como un valor, nunca como SQL capaz de cambiar la estructura de la consulta. El escape manual es propenso a errores y evitable según codificaciones y dialectos. Un WAF es un control compensatorio, no una solución, y los trucos de codificación lo burlan. Una comprobación de longitud no detiene la inyección. Corrígelo en la capa de la consulta.

El XSS almacenado se corrige codificando los datos para el contexto exacto donde se renderizan (cuerpo HTML, atributo, JavaScript, URL) para que el navegador los trate como texto, con una Content-Security-Policy como segunda capa. Poner la palabra «script» en lista negra se evita trivialmente mediante manejadores de eventos, mayúsculas mezcladas y codificaciones. No puedes obligar a tus usuarios a desactivar JavaScript. Pedir a los usuarios que no introduzcan HTML no es un control aplicable. Codifica en la salida, cada vez que renderizas.

El código transitivo se ejecuta en tu aplicación, así que una CVE crítica es tu riesgo. Evalúa si la ruta de código vulnerable es realmente alcanzable, luego remedia subiendo o anulando la versión (o mitigando) y verifica en producción. Ignorarla por ser transitiva deja un agujero conocido que un atacante puede explotar. Silenciar la auditoría solo oculta el aviso. Reinstalar node_modules trae la misma versión vulnerable. Haz seguimiento mediante SCA, no la acalles.

El modelado de amenazas es más barato y eficaz en la fase de diseño, antes de que el código fije las decisiones: recorre los flujos de datos, enumera amenazas con un marco como STRIDE, integra las mitigaciones y revísalo a medida que el diseño evoluciona. Hacerlo solo tras un incidente o en el pentest anual encuentra los problemas cuando ya son caros de corregir y están expuestos. Y fiarse de «desarrolladores cuidadosos» es una esperanza, no un control repetible y auditable.

Los secretos deben vivir en un almacén gestionado con control de acceso, auditoría y rotación, inyectados en runtime, nunca versionados en el control de código. Usa un gestor de secretos (AWS Secrets Manager, HashiCorp Vault) y elimina los valores versionados del historial, luego rótalos porque deben tratarse como comprometidos. El base64 es codificación, no protección: cualquiera puede decodificarlo. Un repo privado sigue propagando el secreto a todos con acceso de clonación, además de los sistemas de CI y los forks. Compilarlo en el binario solo oculta un secreto que sigue siendo trivial de extraer.

Los datos sensibles nunca deberían llegar a los registros: redacta o enmascara en el origen primero para detener la hemorragia, luego remedia los registros históricos y restringe el acceso. PCI DSS prohíbe almacenar así los PAN completos y los CVV, y las contraseñas nunca deberían registrarse. Unos registros «internos» siguen siendo un objetivo de primer orden. Cifrar o restringir el acceso al almacén sigue dejando secretos en texto plano en los registros, accesibles para cualquiera con permiso de lectura — copias de seguridad, pipelines de SIEM y administradores los ven todos.

La prompt injection directa es cuando un usuario escribe instrucciones adversarias directamente en el prompt para anular el system prompt o las reglas de seguridad. La prompt injection indirecta esconde instrucciones maliciosas dentro de contenido externo que el modelo ingiere después —una página web, un correo, un PDF o un documento RAG—, de modo que el ataque se dispara sin que la víctima lo escriba. La inyección indirecta es el mayor riesgo porque el atacante y la víctima son personas distintas, y la carga útil llega en datos en los que la app confía implícitamente.

El manejo inseguro de salidas es confiar en lo que el modelo devuelve y pasarlo a un sistema aguas abajo sin validación ni codificación. Como la salida del modelo es influenciable por el atacante, renderizarla como HTML en bruto causa XSS, pasarla a un recuperador de URL causa SSRF, y pasarla a un shell o una consulta SQL causa inyección de comandos o SQL. La solución es tratar la salida del modelo exactamente como entrada de usuario no confiable: codificación de salida sensible al contexto, listas de permitidos, saneamiento y parametrización antes de que llegue a cualquier sink.

Un jailbreak ataca el alineamiento de seguridad del modelo: engaña al modelo para que produzca contenido que el proveedor intentó prohibir, como instrucciones dañinas. La prompt injection ataca la jerarquía de instrucciones de la aplicación: anula el system prompt del desarrollador o secuestra el comportamiento del modelo dentro de una app, a menudo mediante datos no confiables. Los jailbreaks atacan el modelo; la prompt injection ataca el sistema circundante. Se solapan, pero el objetivo y el límite de confianza que cruzan son distintos.

La cadena de suministro de LLM abarca modelos base, variantes fine-tuneadas, datasets, embeddings, plugins, librerías y la plataforma de alojamiento, cada uno un lugar para introducir riesgo. Las amenazas incluyen descargar pesos de modelo manipulados o con backdoor, fine-tunes maliciosos, datasets envenenados o con licencia contaminada, plugins vulnerables o sobreprivilegiados, y repos de modelos con typosquatting. Defensas: obtener modelos de registros de confianza, verificar integridad y procedencia, mantener un AI bill of materials, escanear y fijar dependencias, verificar plugins y aplicar mínimo privilegio a todo lo que el modelo integre.

El OWASP Top 10 for LLM Applications es la lista de consenso de los riesgos más críticos al construir con grandes modelos de lenguaje. La edición 2025 cubre prompt injection, divulgación de información sensible, supply chain, envenenamiento de datos y modelo, manejo inseguro de salidas, excessive agency, fuga de system prompt, debilidades de vectores y embeddings, desinformación y consumo no acotado. Existe porque las listas tradicionales de appsec no capturan los modos de fallo propios de los LLM, y da a los equipos un vocabulario común y una checklist para priorizar controles.

La seguridad RAG significa tratar cada documento recuperado como entrada no confiable. Riesgos clave: prompt injection indirecta oculta en el contenido recuperado, envenenamiento de la base de conocimiento o los embeddings, y falta de autorización por usuario, de modo que el modelo devuelve datos a los que el usuario no tiene acceso. Las defensas incluyen control de acceso aplicado en la recuperación, procedencia del contenido y verificación en la ingesta, tratar el texto recuperado como datos y no como instrucciones, validación de salidas, y aislar el almacén de vectores por inquilino.

Un agente LLM convierte texto en acciones mediante herramientas y function calls, así que una prompt injection se convierte en una acción real: el riesgo de excessive agency. Asegúralo dando a cada herramienta el mínimo privilegio y alcance que necesite, validando y acotando los argumentos de las herramientas, exigiendo confirmación humana para acciones sensibles o irreversibles, ejecutando en sandbox, limitando la tasa y presupuestando las llamadas, y registrando cada invocación de herramienta. Nunca dejes que la salida del modelo, influida por datos no confiables, autorice directamente una acción de alto impacto.

Las apps LLM filtran datos de varias formas: el modelo memoriza y regurgita datos sensibles de entrenamiento o fine-tuning, el system prompt (que puede guardar secretos o lógica) se extrae, los documentos RAG recuperados exponen datos que el usuario no debería ver, y el contexto de un usuario o sesión se mezcla con otro. La prevención implica minimización de datos antes del entrenamiento, nunca poner secretos en los prompts, aplicar autorización por usuario en la recuperación, filtrado de salidas y redacción de PII, y aislamiento por inquilino.

El envenenamiento de datos de entrenamiento es cuando un atacante manipula los datos usados para preentrenar, hacer fine-tuning o generar los embeddings de un modelo, de modo que el modelo resultante se comporte de forma maliciosa: incrustando un disparador de backdoor, inyectando sesgo o degradando la precisión. Explota el hecho de que los modelos rastrean y confían en datasets enormes, a menudo de origen web. Las defensas incluyen curar y firmar las fuentes de datos, verificaciones de procedencia e integridad, detección de anomalías en los datos de entrenamiento, versionado de datasets, y limitar quién puede contribuir a los corpus de entrenamiento y RAG.

Integra la seguridad en cada fase del SDLC en lugar de probar al final: los requisitos incluyen requisitos de seguridad y privacidad, el diseño incluye modelado de amenazas, el desarrollo sigue normas de codificación segura con SAST, las pruebas añaden DAST y revisiones, y el lanzamiento requiere aprobación, todo gobernado por la política, la separación de funciones y el control de cambios. Corregir los fallos pronto es drásticamente más barato que tras el lanzamiento.

Parte de una imagen base mínima y de confianza (distroless o slim) para reducir la superficie de ataque, escanea las imágenes en busca de CVE conocidas en la CI y en el registro, fija y verifica los digests de las imágenes, ejecuta con un usuario no-root y evita incrustar secretos. Firma las imágenes y aplica políticas de admisión para que solo se ejecuten imágenes escaneadas y firmadas. Reconstruye con regularidad para que las capas base parcheadas se propaguen.

El RBAC controla qué pueden hacer las identidades contra la API de Kubernetes — los Roles y ClusterRoles conceden verbos sobre recursos, vinculados a sujetos vía RoleBindings — y debe seguir el privilegio mínimo, evitando cluster-admin y comodines. Las políticas de red controlan el tráfico de pod a pod, que permite todo por defecto hasta que aplicas un default-deny y luego permites explícitamente los flujos requeridos. Juntos limitan el radio de impacto si un pod o token se ve comprometido.

Almacena los secretos en un servicio gestionado dedicado (Secrets Manager, Parameter Store, Vault), cifrados con una clave de KMS, y concede el acceso mediante roles IAM para que las cargas de trabajo los recuperen en tiempo de ejecución con credenciales de corta duración. Nunca incrustes secretos en el código, las imágenes de contenedor o archivos .env versionados. Añade rotación automática, políticas de clave acotadas y registro de auditoría para que cada recuperación sea rastreable.

La CI/CD es de alto valor porque guarda las credenciales de despliegue y ejecuta código no confiable. Los riesgos incluyen dependencias y acciones de build comprometidas, secretos filtrados o demasiado amplios, acciones de terceros mutables, y runners o confianza OIDC con privilegios excesivos. Redúcelos con dependencias fijadas y verificadas, federación OIDC de corta duración en vez de claves de larga duración, privilegio mínimo acotado a repos/ramas concretos, runners efímeros aislados, y artefactos firmados con procedencia rastreada (SLSA).

Una firma digital es el hash de un mensaje transformado con la clave privada del firmante. El verificador recalcula el hash, aplica la clave pública del firmante y comprueba que coinciden. Como solo el firmante posee la clave privada, una firma válida prueba que el mensaje proviene de él (autenticidad), no fue alterado (integridad) y que no puede negarlo de forma creíble (no repudio).

Un HMAC es un código de autenticación de mensajes con clave: aplica un hash al mensaje junto con una clave secreta mediante una construcción anidada (hash interno y externo con rellenos derivados de la clave). Prueba tanto la integridad (el mensaje no fue alterado) como la autenticidad (proviene de alguien que posee la clave). Un hash simple no prueba ninguna de las dos, ya que cualquiera puede recalcularlo; HMAC además resiste ataques de extensión de longitud.

Un JWT tiene tres partes en base64url —cabecera, carga útil (reclamaciones) y firma— unidas por puntos. El servidor firma la cabecera y la carga útil con un secreto o una clave privada, y verifica esa firma en cada solicitud para confiar en las reclamaciones sin estado de sesión en el servidor. Errores: aceptar alg=none, la confusión de claves de RS256 a HS256, no validar expiración/emisor/audiencia, poner secretos en la carga útil legible, y la falta de una vía de revocación.

La aplicación redirige al usuario al servidor de autorización para iniciar sesión y dar consentimiento. El servidor redirige de vuelta con un código de autorización de corta duración. El backend de la aplicación intercambia luego ese código (más su secreto de cliente) en el endpoint de token por un token de acceso, sobre un canal trasero de servidor a servidor. Esto mantiene los tokens fuera del navegador/la URL. Los clientes públicos añaden PKCE para vincular el código al solicitante original.

Almacena las contraseñas usando una función de hashing de contraseñas deliberadamente lenta, salada y adaptativa —bcrypt, scrypt o Argon2— nunca un hash rápido de propósito general como SHA-256 o MD5. Los hashes rápidos están hechos para la velocidad, así que atacantes con GPU pueden probar miles de millones de intentos por segundo contra una base de datos filtrada. Los hashes lentos tienen un factor de trabajo ajustable (y un coste de memoria) que hace cada intento caro, manteniendo la fuerza bruta impracticable incluso tras una filtración.

Una sal es un valor aleatorio único generado por usuario y combinado con la contraseña antes del hashing. Garantiza que contraseñas idénticas produzcan hashes diferentes y vuelve inútiles los ataques precalculados como las tablas arcoíris, ya que el atacante necesitaría una tabla distinta por sal. Las sales se almacenan junto al hash. Una pimienta es un valor secreto adicional, el mismo para todos los usuarios, guardado por separado (por ejemplo, en la configuración de la app o un HSM) para que una filtración de la base de datos sola no baste.

TOTP (contraseña de un solo uso basada en tiempo) combina un secreto compartido, establecido en el registro, con la hora actual dividida en ventanas fijas (normalmente 30 segundos). Ejecuta HMAC sobre el contador del paso de tiempo con el secreto, luego trunca el resultado a un código de 6 dígitos. Tanto la app como el servidor tienen el mismo secreto y reloj, así que calculan independientemente el mismo código, sin necesidad de llamada de red. El código rota en cada ventana.

La firma vincula criptográficamente un artefacto con su productor, para que los consumidores puedan verificar que no fue manipulado ni sustituido. La procedencia son metadatos firmados que describen cómo, dónde y a partir de qué fuente se construyó el artefacto. Juntas — mediante herramientas como Sigstore para la firma sin claves y el framework SLSA para los niveles de procedencia — permiten a quien despliega verificar que una imagen proviene del pipeline y la fuente esperados, frustrando la manipulación y los ataques de sustitución de dependencias.

Escanea las imágenes en busca de CVE conocidas en paquetes del SO y bibliotecas de la app, además de configuraciones erróneas y secretos incrustados, tanto en el momento del build como de forma continua en el registro — porque aparecen nuevas CVE después de construir una imagen. Usa imágenes base mínimas o distroless para reducir la superficie de ataque, fija y referencia las imágenes base por digest, y ejecuta el contenedor como no-root. El escaneo es necesario pero no sustituye a la protección en runtime.

Los lockfiles fijan las versiones y hashes exactos de las dependencias para que cada build resuelva los mismos bytes verificados — haciendo los builds reproducibles y bloqueando actualizaciones maliciosas silenciosas. Fijar por digest, verificar los hashes de integridad y acotar los paquetes internos a un registro privado también defienden contra la confusión de dependencias, donde un atacante publica un paquete público de versión superior que coincide con un nombre interno para secuestrar la resolución. El principio: nunca dejar que el build descargue silenciosamente código no verificado.

El escaneo de IaC analiza estáticamente definiciones de Terraform, CloudFormation, Kubernetes y similares contra una política para detectar configuraciones erróneas — buckets S3 públicos, grupos de seguridad abiertos, cifrado ausente — antes de que se aprovisionen. Como la misma plantilla aprovisiona muchos recursos, corregirla una vez evita la deriva repetida, y detectarlo antes de aplicar es mucho más barato que remediar recursos cloud en producción. Las herramientas incluyen Checkov, tfsec y KICS, idealmente aplicadas como barreras de policy-as-code.

El SAST lee el código fuente sin ejecutarlo y encuentra pronto fallos como los puntos de inyección, pero con muchos falsos positivos. El DAST ataca la aplicación en ejecución desde fuera, sin visibilidad del código, y encuentra problemas realmente explotables pero tarde y con cobertura superficial. El IAST instrumenta la aplicación en ejecución para correlacionar el comportamiento en runtime con el código, obteniendo resultados precisos con contexto del código, pero necesita una aplicación ejercitada y soporte de un agente.

Usa defensa en profundidad: los hooks pre-commit (p. ej. gitleaks) atrapan secretos antes de que lleguen, el escaneo de CI en el servidor atrapa lo que se cuela, y escaneos periódicos de todo el historial encuentran filtraciones antiguas. Y lo crítico: un secreto que llegó a un repositorio remoto debe tratarse como comprometido y rotarse — borrar el commit no ayuda porque vive en el historial, los forks y los logs. Combina esto con un gestor de secretos real para que los secretos no estén en el código en absoluto.

Rompe la build solo ante hallazgos de alta confianza, alta severidad y recién introducidos; avisa (sin bloquear) en todo lo demás para que los desarrolladores sigan confiando en el gate. Gestiona los falsos positivos con reglas afinadas, baselining de los problemas preexistentes y supresiones documentadas, acotadas en el tiempo y revisadas, en lugar de desactivar los escáneres. Un gate que avisa en falso acaba ignorándose o esquivándose, así que la calidad de la señal lo es todo.

El shift left consiste en mover la seguridad antes — al diseño, al IDE y al pull request — donde los problemas son más baratos de corregir que en producción. Evitas bloquear a los desarrolladores haciendo que el camino seguro sea el camino fácil: feedback rápido y en contexto, gates de bajo falso positivo que solo fallan en duro ante problemas nuevos de alta severidad, configuraciones seguras por defecto y plantillas de paved road, y tratando la seguridad como un facilitador en lugar de un veto tardío.

El SCA inventaría los componentes de código abierto y de terceros que una aplicación incorpora —incluidas las dependencias transitivas— y señala los que tienen CVE conocidos o licencias problemáticas. Importa porque la mayor parte del código moderno son dependencias que no escribiste tú, y un único paquete transitivo vulnerable (como Log4j) puede exponer toda la aplicación. Un buen SCA prioriza por alcanzabilidad y explotabilidad, no solo por el recuento bruto de CVE.

Un SBOM es un inventario legible por máquina de cada componente, biblioteca y dependencia de un software, con versiones e idealmente hashes. Importa porque cuando aparece una nueva vulnerabilidad, puedes consultar tus SBOM para responder al instante a «¿estamos afectados y dónde?» en lugar de improvisar. Los dos estándares dominantes son SPDX y CycloneDX, y los SBOM son cada vez más exigidos por la normativa y las compras.

La codificación (como Base64) es un cambio de formato reversible sin secreto — no es seguridad. El cifrado es reversible con una clave y protege la confidencialidad. El hashing es una función unidireccional que produce un resumen de longitud fija, usado para comprobaciones de integridad y almacenamiento de contraseñas, y no puede revertirse para obtener la entrada.

Confirma el XSS. Si alert() se disparó siquiera, el navegador analizó y ejecutó tu JavaScript inyectado en el contexto de la página: esa es la vulnerabilidad. Una ventana vacía solo significa que el argumento de cadena que pasaste no se mostró como esperabas (el manejo de comillas, la codificación o la alteración del contexto rompieron el mensaje), no que el payload esté bloqueado. El punto de ejecución está activo; a partir de ahí refinas el payload.

Comprime primero y luego cifra. Un buen cifrado produce una salida estadísticamente indistinguible de lo aleatorio, así que el texto cifrado no tiene patrones que comprimir: comprimir después es inútil. La advertencia importante: comprimir juntos datos secretos y datos controlados por el atacante antes de cifrar puede filtrar información a través de la longitud del texto cifrado, que es exactamente lo que hacen los ataques CRIME y BREACH.

No. CORS no es una defensa contra el CSRF: en realidad afloja la política del mismo origen para que una página pueda leer respuestas entre orígenes que de otro modo no podría. El CSRF no necesita leer la respuesta; solo necesita que el navegador de la víctima envíe una petición autenticada que cambie el estado. Las defensas reales son los tokens anti-CSRF, el atributo de cookie SameSite y comprobar Origin/Referer.

La codificación transforma los datos a otro formato por compatibilidad y es totalmente reversible por cualquiera sin clave (p. ej. Base64, codificación de URL): no aporta confidencialidad. El cifrado solo es reversible con una clave y es lo que aporta confidencialidad. El hashing es una función unidireccional: no puedes recuperar la entrada a partir de la salida, por lo que sirve para comprobaciones de integridad y almacenamiento de contraseñas (con sal y una KDF lenta).

Porque son rápidos. MD5 y SHA-256 están diseñados para la velocidad, que es exactamente lo contrario de lo que se necesita para las contraseñas: un atacante que roba los hashes puede calcular miles de millones de intentos por segundo en una GPU. La solución es una función de derivación de clave deliberadamente lenta y dura en memoria —bcrypt, scrypt o Argon2— combinada con una sal por usuario y un factor de trabajo ajustable.

La WSTG es una metodología respaldada por una lista de verificación que recorre una aplicación a través de categorías de prueba: recopilación de información, configuración y despliegue, identidad y autenticación, autorización, gestión de sesiones, validación de entradas (inyección/XSS), gestión de errores, criptografía, lógica de negocio y lado cliente. Ofrece cobertura sistemática con identificadores de prueba estables, de modo que los hallazgos son reproducibles y no se omite nada obvio.

Empieza por entender el modelo de amenazas de la aplicación y dónde maneja entradas no confiables, secretos, autenticación y autorización. Usa SAST para escanear ampliamente y DAST contra la aplicación en ejecución, pero trata la salida de las herramientas como pistas, no como hallazgos — descarta falsos positivos. Luego dedica el tiempo humano a las áreas de alto valor y dependientes del contexto que las herramientas pasan por alto: lógica de autorización, lógica de negocio, uso de criptografía y fronteras de confianza. Rastrea el flujo de datos desde la fuente hasta el sink.

Un SDLC seguro integra la seguridad en cada fase en lugar de probar al final: requisitos (casos de seguridad y de abuso), diseño (modelado de amenazas), implementación (estándares de codificación segura, SAST/SCA en el IDE y la CI), pruebas (DAST, pentest), liberación (gates y aprobación) y operación (monitorización, parcheo, retroalimentación). El shift-left mueve los defectos antes, donde son baratos de corregir; modelos de madurez como OWASP SAMM y BSIMM miden cuán bien lo haces realmente.

El modelado de amenazas responde a cuatro preguntas: qué estamos construyendo, qué puede salir mal, qué hacemos al respecto y si hicimos un buen trabajo. Diagramas el sistema (a menudo un diagrama de flujo de datos con fronteras de confianza), enumeras amenazas con un marco como STRIDE, priorizas por riesgo y asignas mitigaciones. PASTA añade un matiz centrado en el riesgo y el atacante; los árboles de ataque descomponen un único objetivo. Hacerlo en tiempo de diseño es mucho más barato que parchear producción.

Un proxy directo se sitúa delante de los clientes y hace peticiones salientes en su nombre — para control de salida, filtrado, cacheo y anonimato. Un proxy inverso se sitúa delante de los servidores y recibe peticiones entrantes en su nombre — para balanceo de carga, terminación TLS, cacheo y como fachada de seguridad para un WAF. La dirección a la que mira, lado cliente o lado servidor, es la distinción clave.

Identifica la stack a partir de las cabeceras y el código fuente, y luego haz fuerza bruta de directorios y archivos con gobuster o feroxbuster usando un buen diccionario y las extensiones relevantes. Busca paneles de administración, copias de seguridad, archivos de configuración y puntos de subida, y comprueba los hosts virtuales cuando el sitio responde a un nombre de host.

Por separado, la SQLi expone o modifica datos y puede llegar al RCE; la XSS almacenada secuestra sesiones en el navegador de las víctimas. Encadenadas, puedes usar la SQLi para plantar una carga XSS almacenada que se dispara en la sesión de un admin, robar su sesión y escalar al control total de la aplicación.

El cifrado es reversible: con la clave recuperas el texto plano; protege la confidencialidad. El hashing es una función unidireccional que produce un resumen de tamaño fijo que no se puede revertir; verifica integridad e identidad. Las contraseñas deben hashearse con un algoritmo lento y salado como bcrypt o Argon2, nunca cifrarse.

Nunca codifiques secretos en el código fuente ni los subas a git. Guárdalos en un gestor de secretos o bóveda dedicada, inyéctalos en tiempo de ejecución, acota el acceso con privilegios mínimos, rótalos con regularidad y prefiere credenciales dinámicas de corta duración frente a las estáticas persistentes. Audita cada acceso.

Un SDLC seguro integra la seguridad en cada fase en lugar de añadirla al final. Los requisitos incluyen casos de seguridad y de abuso, el diseño añade modelado de amenazas, el desarrollo usa codificación segura y SAST más escaneo de dependencias, las pruebas añaden DAST y pruebas de penetración, y operaciones añade monitorización, parcheo y respuesta a incidentes — desplazando la seguridad hacia la izquierda.

Forzar TLS en todas partes, autenticar cada solicitud (p. ej. tokens OAuth2/OIDC) y autorizar por objeto para que los usuarios solo alcancen sus propios datos. Añade validación de entradas, limitación de tasa y cuotas, validación de esquema y registro exhaustivo. El fallo de API más común es la autorización a nivel de objeto rota, así que comprueba la propiedad en cada acceso a un recurso.

Content-Security-Policy es una cabecera de respuesta HTTP que indica al navegador qué fuentes de scripts, estilos, imágenes y otros contenidos pueden cargarse y ejecutarse en una página. Al prohibir el script en línea y los orígenes no confiables — idealmente mediante nonces o hashes — actúa como una defensa en profundidad de respaldo que neutraliza las cargas útiles de XSS inyectadas, incluso cuando alguna se cuela.

El CSRF engaña al navegador de un usuario autenticado para que envíe una petición que cambia el estado a un sitio donde está autenticado, abusando del hecho de que las cookies se envían automáticamente. Se detiene con tokens anti-CSRF (un valor secreto por sesión que el atacante no puede leer ni adivinar) y el atributo de cookie SameSite, que impide que las cookies acompañen a las peticiones de sitios cruzados.

El OWASP Top 10 es un documento de concienciación impulsado por la comunidad que clasifica los riesgos de seguridad de aplicaciones web más críticos, actualizado cada pocos años con datos del mundo real. No es una lista de comprobación ni un estándar, sino un punto de partida — las entradas recientes incluyen Control de Acceso Roto (n.º 1), Fallos Criptográficos, Inyección y Diseño Inseguro.

Nunca almacenes contraseñas en texto plano ni cifradas de forma reversible, y nunca con hashes rápidos de propósito general como MD5 o SHA-256. Usa una función de hash de contraseñas lenta y exigente en memoria — Argon2id (preferida) o bcrypt — con una sal aleatoria única por contraseña y un factor de coste ajustado, de modo que un atacante que robe la base de datos no pueda descifrar los hashes de forma viable.

Las sentencias preparadas envían primero la plantilla de la consulta a la base de datos, con marcadores de posición, de modo que la estructura queda fijada antes de que llegue ningún dato del usuario. Los parámetros se vinculan después como datos puros y nunca pueden interpretarse como SQL — así que una entrada como ' OR 1=1 se trata como una cadena literal, no como código. Esta separación es la solución canónica y fiable contra la inyección.

La defensa principal es la codificación de salida contextual — codificar los datos no confiables para el lugar exacto donde aterrizan (cuerpo HTML, atributo, JavaScript, URL). Combínalo con API DOM seguras (textContent en lugar de innerHTML), el autoescapado de los frameworks, la validación de entrada y una Content-Security-Policy como defensa en profundidad de respaldo que limita qué scripts pueden ejecutarse.

La Same-Origin Policy es la regla del navegador según la cual un script de un origen (esquema + host + puerto) no puede leer las respuestas de un origen diferente, lo que protege las sesiones autenticadas. CORS es una relajación controlada: un servidor devuelve cabeceras Access-Control-Allow-Origin para habilitar explícitamente que orígenes concretos lean sus respuestas, por lo que flexibiliza la SOP en lugar de eludirla.

HttpOnly oculta la cookie a JavaScript para que el XSS no pueda robarla mediante document.cookie. Secure garantiza que la cookie solo se envíe por HTTPS, bloqueando la interceptación de red. SameSite controla si la cookie se envía en peticiones entre sitios, mitigando el CSRF. Juntos, endurecen las cookies de sesión frente a las vías más comunes de robo y abuso.

Las cabeceras de seguridad clave incluyen Strict-Transport-Security (fuerza HTTPS, bloquea el SSL stripping), Content-Security-Policy (limita las fuentes de scripts, mitiga el XSS), X-Frame-Options o CSP frame-ancestors (bloquea el clickjacking), X-Content-Type-Options: nosniff (detiene el MIME sniffing) y Referrer-Policy (controla la filtración del referente). Cada una aborda una clase de ataque concreta.

La inyección SQL permite que la entrada de un atacante altere una consulta. Las técnicas en banda devuelven datos directamente: la basada en UNION añade un UNION SELECT para extraer columnas adicionales, y la basada en errores filtra datos a través de los mensajes de error de la base de datos. Cuando no hay salida visible, los atacantes usan SQLi a ciegas — la booleana infiere datos de las diferencias de respuesta verdadero/falso, y la basada en tiempo usa retrasos como SLEEP() para leer datos bit a bit.

El SSRF engaña a un servidor para que realice peticiones HTTP (u otras) a un destino elegido por el atacante, abusando de la posición de red del servidor para alcanzar servicios internos tras el cortafuegos. En la nube es especialmente grave porque el servicio de metadatos de instancia (por ejemplo, 169.254.169.254) puede devolver credenciales IAM, convirtiendo un SSRF en un compromiso de la cuenta en la nube.

HTTP no tiene estado — cada petición es independiente y no guarda memoria de las anteriores. Las sesiones añaden estado por encima: tras iniciar sesión, el servidor emite un identificador que el navegador almacena en una cookie y reenvía en cada petición. Las sesiones del lado del servidor mantienen el estado en el servidor indexado por un ID de sesión opaco; los tokens sin estado como los JWT ponen el estado firmado en el propio token para que el servidor pueda verificar sin almacenamiento.

Todo XSS inyecta un script controlado por el atacante en el navegador de una víctima. El XSS almacenado persiste la carga útil en el servidor (por ejemplo, un comentario) y afecta a todos los que la ven; el XSS reflejado rebota la carga útil desde el servidor en una sola respuesta, normalmente mediante un enlace manipulado; el XSS basado en el DOM nunca llega a la lógica del servidor — JavaScript vulnerable del lado del cliente escribe entrada no confiable en la página.

El XXE abusa de un analizador XML que resuelve las entidades externas definidas en la DTD de un documento. Un atacante declara una entidad que apunta a un archivo local o una URL interna, y el analizador la obtiene — permitiendo la divulgación de archivos, el SSRF y la denegación de servicio. La solución es desactivar el procesamiento de DTD y la resolución de entidades externas en la configuración del analizador.