Convierte el tráfico HAR de Playwright en hallazgos de seguridad con un escáner MCP

Los ingenieros de QA se ocupan a diario de APIs, solicitudes HTTP, flujos de inicio de sesión, automatización de navegadores, pipelines CI/CD y el comportamiento de las aplicaciones. Esto coincide en gran medida con la seguridad de las aplicaciones, lo que plantea una pregunta: ¿podrían las pruebas automatizadas generar ya el doble de datos como entrada para las pruebas de seguridad?

Una respuesta es un servidor MCP (Model Context Protocol) que escanea el tráfico de pruebas grabado en busca de problemas de seguridad. El proceso es sencillo: ejecutar la automatización de QA, capturar el tráfico HTTP, escanear ese tráfico en busca de problemas y permitir que una IA ayude a interpretar los resultados. Lo importante es que el escáner nunca envía solicitudes adicionales a la aplicación.

Dos mundos que comparten una misma fuente de datos

La seguridad y las pruebas de calidad suelen tratarse como actividades separadas. La rutina de pruebas de calidad consiste en escribir pruebas, ejecutarlas, validar la funcionalidad y generar informes. El trabajo de seguridad, por su parte, se lleva a cabo en otro lugar: se ejecutan herramientas de seguridad, se escanea la aplicación, se investigan las vulnerabilidades y se informan los hallazgos.

No obstante, las pruebas automatizadas ya interactúan con la aplicación. Llaman a APIs, envían encabezados de autenticación y cookies, reciben respuestas y acceden a endpoints. Todo eso constituye tráfico HTTP, y puede servir como fuente de señales de seguridad.

Los archivos HAR como puente

Herramientas como Playwright pueden guardar la actividad de red del navegador como un archivo HAR (HTTP Archive). Cada transacción HTTP que contiene incluye detalles como:

• URL de las solicitudes y métodos HTTP
• Encabezados de solicitud y respuesta
• Cookies
• Cuerpos de solicitud y respuesta
• Códigos de estado y otros metadatos

Esto genera una cadena de procesos que comienza con la automatización de pruebas de calidad y termina con el escaneo del tráfico que se generó:

QA Automation
      │
      ▼
HTTP Traffic
      │
      ▼
    HAR File
      │
      ▼
Security Scanner
      │
      ▼
Security Findings

No se genera una nueva ronda de tráfico. El escáner analiza lo que ya han capturado las pruebas, lo que hace que el enfoque sea pasivo.

Arquitectura

El escáner es una herramienta de TypeScript que lee archivos HAR y busca señales relevantes para la seguridad. Su estructura es deliberadamente sencilla:

Playwright
                        │
                        ▼
                 Network Traffic
                        │
                        ▼
                     HAR File
                        │
                        ▼
                   HAR Parser
                        │
                        ▼
              Normalized Transactions
                        │
                        ▼
                 Security Rules
                   │         │
                   ▼         ▼
                MCP Tool   CLI Gate
                   │         │
                   ▼         ▼
                 AI        CI/CD

Una decisión clave en el diseño fue dividir el analizador HAR, un modelo de transacciones normalizado, las reglas de seguridad y el motor de escaneo en partes separadas. Solo el analizador se ocupa del formato HAR. Las reglas nunca ven la estructura original de HAR y trabajan con transacciones normalizadas, por lo que añadir una nueva regla más adelante es sencillo.

Verificaciones en la primera versión

Falta HSTS. El escáner marca como problema las respuestas que carecen de este encabezado:

Strict-Transport-Security

HSTS hace que los navegadores exijan el uso de HTTPS, y constituye una parte importante de la configuración segura.

HTTP simple. Las solicitudes realizadas a través de

http://

en lugar de

https://

Señala los puntos finales inseguros que aparecen accidentalmente durante las pruebas habituales.

Atributos de las cookies. Se revisan las cookies en busca de indicadores de protección:

Secure
HttpOnly
SameSite

Una cookie de autenticación o de sesión que carezca de los atributos adecuados merece ser examinada.

Valores similares a secretos en las respuestas. Imagine una respuesta como esta:

{
  "apiKey": "..."
}

Un valor que parece una credencial y que se devuelve a un cliente representa un problema potencial. Es especialmente interesante porque una prueba de calidad puede detectarlo de forma natural, sin que se haya escrito una prueba de seguridad específica para ello.

Parámetros URL sensibles. A veces, los secretos terminan incluidos en las URLs:

/api/user?token=...

El escáner examina las URLs en busca de nombres de parámetros y patrones que parezcan sensibles. Las URLs terminan en registros, historial del navegador, proxies, sistemas de análisis y otros lugares, por lo que esto es importante.

Números de tarjetas de pago. Esta fue una de las reglas más interesantes. El escáner detecta valores que parecen números de tarjeta y los valida con el algoritmo Luhn. Un número aleatorio de 16 dígitos no dice mucho, pero un valor que se asemeja a un número de tarjeta y pasa la verificación Luhn es una señal más fuerte de que los datos de pago podrían estar expuestos. La regla combina la detección de patrones con una validación real.

Configuraciones CORS riesgosas. El escáner busca combinaciones peligrosas. Un origen comodín:

Access-Control-Allow-Origin: *

junto con las credenciales permitidas:

Access-Control-Allow-Credentials: true

Esto justifica una investigación. También detecta servidores que parecen devolver el Origin de la solicitud sin una validación adecuada.

Hacer que el escáner sea utilizable por la IA

El Model Context Protocol es una forma estándar para que las aplicaciones de IA utilicen herramientas y datos externos. En lugar de limitarse a un escáner independiente, el proyecto lo expone como una herramienta utilizable por la IA. El servidor MCP publica una herramienta:

secscan_scan_har

Un cliente de IA proporciona un archivo HAR, ejecuta el escáner y recibe los resultados estructurados. El flujo es el siguiente:

HAR File
                 │
                 ▼
            MCP Server
                 │
                 ▼
          Security Scanner
                 │
                 ▼
          Security Findings
                 │
                 ▼
            AI Client
                 │
                 ▼
        Explain / Investigate

Leer un informe línea por línea ya no es la única opción, ya que una persona puede simplemente hacer preguntas sobre los resultados. Las consultas típicas serían cuáles hallazgos tienen mayor gravedad, qué está relacionado con la autenticación o por qué una configuración específica de CORS es riesgosa. El escáner proporciona las pruebas, y la IA ayuda a explicarlas.

Evitar que la IA influya en la decisión de aprobación/rechazo

La IA es útil para explicar los hallazgos, resumir resultados, ayudar a investigar pruebas, sugerir soluciones y responder preguntas sobre un escaneo. Sin embargo, un despliegue en producción no debería depender de si un modelo considera que algo es vulnerable. Por eso, el proyecto también cuenta con una puerta de seguridad CLI determinística:

npm run gate -- test-results/network.har

Cuando aparecen hallazgos críticos, el escáner puede hacer que la compilación falle. Eso da dos vías separadas. La primera es el análisis asistido por IA:

AI-Assisted Analysis

HAR
 ↓
MCP
 ↓
AI
 ↓
Explain / Investigate / Triage

El segundo es una puerta de seguridad determinista:

Deterministic Security Gate

HAR
 ↓
Scanner
 ↓
Critical Finding?
 ↓
FAIL BUILD

La división es importante. Utilice la IA donde el razonamiento y la interacción aporten valor, y emplee reglas deterministas cuando las decisiones de aprobación/rechazo deban ser predecibles.

Integrándolo en una pipeline de Playwright

Considere un trabajo de CI de Playwright existente con su paso de prueba habitual:

- name: Run Playwright tests
  run: npx playwright test

Agregue un paso de seguridad justo después de él:

- name: Security Gate
  run: npm run gate -- test-results/network.har

Los mismos tests de calidad ahora generan dos tipos de pruebas: funcionales y de seguridad. El flujo de trabajo general se ve así:

Code
 │
 ▼
Build
 │
 ▼
Playwright Tests
 │
 ▼
Capture HAR
 │
 ▼
Passive Security Scan
 │
 ▼
Security Gate
 │
 ▼
Deploy

Ese es el aspecto más atractivo de la idea. Un flujo de trabajo de seguridad separado no siempre es necesario para cada señal básica, ya que algunas verificaciones pueden realizarse de forma natural dentro del pipeline de control de calidad existente.

La difícil pregunta de diseño

Escribir el servidor MCP no fue la parte difícil; lo complicado fue decidir cómo estructurar los datos entre el analizador HAR y las reglas de seguridad. HAR es un formato detallado, y si cada regla tiene que entenderlo directamente, el mantenimiento se vuelve extremadamente complicado. Una representación intermedia resuelve ese problema:

HAR
 │
 ▼
Parser
 │
 ▼
Transaction
 │
 ▼
Security Rules

Las reglas no tienen en cuenta de dónde proviene una transacción. Reciben algo que ya entienden, lo que facilita la expansión del escáner.

Qué podría venir después

Esta es una primera versión, con mucho espacio para crecer. Las verificaciones posibles incluyen:

• Análisis de la Política de Seguridad de Contenido
• X-Content-Type-Options y Referrer-Policy
• Problemas de Cache-Control
• Exposición de JWT
• Debilidades en la autenticación y las sesiones
• Exposición de datos sensibles
• Más verificaciones CORS
• Señales relacionadas con la autorización

Los hallazgos también podrían incluir pruebas más detalladas, estructuradas de esta manera:

Finding
Severity
Rule
Evidence
Request
Response
Impact
Remediation

La capa MCP podría llegar a responder a preguntas como “¿Qué hallazgos deben investigarse primero?”, “¿Varios hallazgos son causados por el mismo problema de configuración?” y “Explique este hallazgo a un desarrollador.”

La integración con CI es otra dirección: GitHub Actions, comentarios de seguridad en las solicitudes de integración, salida SARIF, umbrales de gravedad, hallazgos de referencia y detección de regresiones de seguridad. El objetivo es que las pruebas de seguridad se perciban como una puerta adicional de calidad y no como algo separado.

Por qué las personas de QA están en una posición ideal

Gran parte de lo que hacen los ingenieros de QA a diario también es fundamental para la seguridad de las aplicaciones: HTTP, APIs, autenticación y autorización, automatización de pruebas, CI/CD, análisis del comportamiento y las fallas de las aplicaciones. El desarrollo de una herramienta profundiza la comprensión más allá de los cursos o certificados por sí solos. Un proyecto de este tipo aborda, uno tras otro, el análisis de archivos HAR, la seguridad de HTTP, las cookies, CORS, la detección de datos secretos y sensibles, las reglas de seguridad, MCP, las puertas de entrada de CLI y CI/CD.

Los beneficios van más allá de simplemente tener otro repositorio: demuestran cómo los datos de automatización de QA pueden convertirse en inteligencia de seguridad. Las pruebas ya monitorean el comportamiento de las aplicaciones, los archivos HAR lo registran de forma estructurada, las reglas extraen señales útiles del tráfico y MCP permite que los clientes basados en IA accedan a esas capacidades. Juntos, forman una idea integral:

QA Automation
      +
Application Security
      +
AI
      +
DevSecOps

La idea clave es que las pruebas de seguridad no necesitan comenzar con otro escaneo más. Pueden iniciarse con las pruebas de tráfico que ya se realizan. La automatización de pruebas de calidad, la seguridad de aplicaciones, la inteligencia artificial y DevSecOps juntos pueden ofrecer más posibilidades y abarcar más áreas que cualquiera de ellos por separado.