Preguntas de entrevista de Web Security

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. 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.

En gran medida no. El nombre de host de destino se envía en claro en la extensión SNI del ClientHello de TLS, y tu consulta DNS suele revelarlo también, de modo que un ISP o una red pueden ver QUÉ sitio visitas incluso por HTTPS — solo que no pueden leer la ruta ni el contenido. El ClientHello cifrado (ECH) y el DNS-over-HTTPS pueden cerrar esta brecha, pero no son universales. «HTTPS lo oculta todo» es la idea equivocada.

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. El modo privado/incógnito solo impide que el navegador local guarde historial, cookies y datos de formulario tras la sesión — no hace nada al camino de red. Tu ISP, el proxy de tu empleador, el resolutor DNS y los sitios donde inicias sesión siguen viendo tu actividad. El error es «incógnito = invisible»; en realidad es privacidad frente a otras personas que usan el mismo dispositivo, no anonimato frente a la red.

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.

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.

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.

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.

Demuestra la vulnerabilidad sin perjudicar al cliente ni acumular sus datos: muestra que puedes leer datos arbitrarios mediante la versión de la base, el esquema o una sola muestra anonimizada, y detente ahí. Volcar todo el conjunto de datos personales genera responsabilidad de notificación de brecha y de tratamiento para ambas partes. Eliminar una tabla es destructivo y va mucho más allá de una prueba de concepto. Cifrar la base y exigir una recompensa es extorsión, no una prueba: es un delito, no un hallazgo.

Un informe útil impulsa la remediación: clasifica por riesgo de negocio (probabilidad × impacto), destaca las cadenas de explotación que llevan a un compromiso crítico y da soluciones accionables para cada hallazgo. El orden alfabético entierra lo importante bajo lo que empieza por «A». Lo más largo primero premia la verborrea sobre la gravedad. Eliminar los hallazgos bajos oculta riesgo real y los patrones que el cliente necesita para la defensa en profundidad, dejándolo con una imagen falsamente tranquilizadora.

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.

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.

SPF publica qué IP pueden enviar correo en nombre de un dominio. DKIM añade una firma criptográfica para que el receptor verifique que el mensaje no fue alterado y proviene del dominio. DMARC liga los resultados de SPF/DKIM al encabezado From: visible mediante la «alineación», indica a los receptores qué hacer ante un fallo (none/quarantine/reject) y envía informes. SPF y DKIM por sí solos no protegen el From que ve el usuario; DMARC es lo que lo impone.

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.

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.

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 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.

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.

No. El candado significa que el transporte está cifrado y que el certificado es válido para ese dominio: no dice nada sobre si el operador es honesto o el contenido es malicioso. Los certificados gratuitos y automatizados hacen que los sitios de phishing y malware casi siempre tengan también un candado perfectamente válido. HTTPS protege el canal, no el destino.

Mantén los access tokens de corta duración (minutos) para que uno robado expire rápido, y usa refresh tokens de mayor duración para obtener nuevos access tokens sin volver a pedírselo al usuario. Rota los refresh tokens en cada uso y detecta la reutilización de un token ya consumido como señal de robo, revocando la cadena. El objetivo es equilibrar la limitación de la ventana de un token comprometido frente a no obligar a los usuarios a reautenticarse constantemente.

La divulgación coordinada de vulnerabilidades es un proceso en el que un investigador reporta un fallo en privado al fabricante, ambas partes acuerdan la remediación y un plazo, y los detalles se publican solo cuando hay un parche disponible (o vence el plazo acordado). Equilibra dar tiempo a los defensores para parchear con el derecho del público a saber. Un fichero security.txt y una política clara hacen que reportar sea sin fricciones; los programas de bug bounty añaden recompensas estructuradas encima.

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.

PTES define siete fases: pre-engagement (alcance, reglas de enfrentamiento, autorización), recopilación de inteligencia (OSINT, reconocimiento), modelado de amenazas, análisis de vulnerabilidades, explotación, post-explotación (pivoteo, datos de valor, persistencia) e informe. La estructura hace que los proyectos sean repetibles, defendibles y ligados al riesgo de negocio en lugar de hacking improvisado. El pre-engagement y el informe son las fases que los junior subestiman.

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.

Una pentest avanza por el precompromiso (alcance y reglas de enfrentamiento), el reconocimiento, el escaneo y la enumeración, la explotación, la postexplotación y el informe. Cada fase alimenta la siguiente, y el informe es donde realmente se entrega el valor al cliente.

Un escaneo de vulnerabilidades es un inventario automatizado y en amplitud de debilidades potenciales, a menudo con falsos positivos. Una prueba de penetración la dirige un humano: valida los hallazgos, los encadena y demuestra un impacto de negocio real mediante una explotación efectiva.

Un buen informe sirve a dos públicos: un resumen ejecutivo que encuadra el riesgo de negocio para la dirección, y hallazgos detallados y reproducibles con evidencias, calificaciones de riesgo precisas y remediación priorizada para el equipo técnico. El informe — no el exploit — es el entregable.

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.

Examina el correo sin hacer clic: revisa las cabeceras y la autenticación del remitente (SPF/DKIM/DMARC), inspecciona las URL y adjuntos en un sandbox o con herramientas de reputación, y luego mide el alcance: quién más lo recibió, si alguien hizo clic o introdujo credenciales. Según los hallazgos, remedia purgando el correo, bloqueando los indicadores y restableciendo las credenciales expuestas.

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.