Transformer le trafic HAR de Playwright en résultats de sécurité à l’aide d’un scanner MCP

Les ingénieurs QA s’occupent quotidiennement des API, des requêtes HTTP, des flux de connexion, de l’automatisation des navigateurs, des pipelines CI/CD ainsi que du comportement des applications. Cela chevauche fortement la sécurité des applications, ce qui soulève une question : les tests automatisés pourraient-ils déjà fournir une double source d’informations pour les tests de sécurité ?

Une réponse possible est un serveur MCP (Model Context Protocol) qui analyse le trafic de test enregistré à la recherche de problèmes de sécurité. Le processus est simple : exécuter l’automatisation QA, capturer le trafic HTTP, le scanner pour détecter les problèmes et faire appel à une intelligence artificielle pour interpréter les résultats. Ce qui est notable, c’est que le scanner ne envoie jamais de requêtes supplémentaires à l’application.

Deux mondes partageant une même source de données

La sécurité et les tests de qualité sont généralement considérées comme des activités distinctes. La routine de tests de qualité consiste à écrire des tests, à les exécuter, à valider la fonctionnalité et à générer des rapports. Le travail de sécurité, quant à lui, a lieu ailleurs : utilisation d’outils de sécurité, analyse de l’application, investigation des vulnérabilités et rapport des constatations.

Pourtant, les tests automatisés communiquent déjà avec l’application. Ils appellent des API, envoient des en-têtes d’authentification et des cookies, reçoivent des réponses et accèdent à des points de terminaison. Tout cela constitue du trafic HTTP, qui peut servir de source de signaux de sécurité.

Les fichiers HAR en tant que pont

Des outils tels que Playwright peuvent enregistrer l’activité réseau du navigateur sous forme de fichier HAR (HTTP Archive). Chaque transaction HTTP qu’il contient inclut des détails tels que :

• Les adresses URL et les méthodes HTTP des requêtes
• Les en-têtes de requête et de réponse
• Les cookies
• Le corps des requêtes et des réponses
• Les codes d’état et d’autres métadonnées

Cela produit un pipeline qui commence par l’automatisation des tests de qualité et se termine par l’analyse du trafic généré :

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

Aucun nouveau flux de trafic n’est généré. Le scanner analyse ce que les tests ont déjà capturé, ce qui rend cette approche passive.

Architecture

Le scanner est un outil TypeScript qui lit des fichiers HAR et recherche des signaux pertinents pour la sécurité. Sa structure est délibérément simple :

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

L’une des principales décisions de conception a été de diviser le analyseur HAR, un modèle de transaction normalisé, les règles de sécurité ainsi que le moteur de balayage en composants distincts. Seul l’analyseur traite le format HAR. Les règles ne voient jamais la structure originale HAR et fonctionnent plutôt sur des transactions normalisées, ce qui rend facile l’ajout de nouvelles règles par la suite.

Vérifications dans la première version

HSTS manquant. Le balayeur signale les réponses ne contenant pas cet en-tête :

Strict-Transport-Security

HSTS oblige les navigateurs à utiliser HTTPS, et c’est un élément essentiel d’une configuration sécurisée.

HTTP simple. Les requêtes effectuées via

http://

plutôt que

https://

Indique les points d’entrée accidentellement non sécurisés qui apparaissent lors des exécutions de test ordinaires.

Attributs des cookies. Les cookies sont vérifiés pour détecter des indicateurs de protection :

Secure
HttpOnly
SameSite

Un cookie d’authentification ou de session manquant des attributs appropriés mérite une attention particulière.

Valeurs similaires à des secrets dans les réponses. Imaginez une réponse telle que :

{
  "apiKey": "..."
}

Une valeur ayant l’air d’une clé d’authentification renvoyée à un client représente un problème potentiel. Cela est d’autant plus intéressant qu’un test de qualité peut y tomber naturellement, sans qu’aucun test de sécurité spécifique n’ait été conçu à cette fin.

Paramètres URL sensibles. Des secrets se retrouvent parfois dans les URLs :

/api/user?token=...

Le scanner examine les URL à la recherche de noms de paramètres et de motifs qui semblent sensibles. Les URL se retrouvent dans les journaux, l’historique du navigateur, les proxies, les systèmes d’analyse et d’autres endroits, ce qui rend ce point important.

Numéros de cartes de paiement. C’était l’une des règles les plus intéressantes. Le scanner repère des valeurs qui ressemblent à des numéros de carte et les valide à l’aide de l’algorithme de Luhn. Un numéro aléatoire de 16 chiffres n’a que peu d’importance, mais une valeur qui ressemble à un numéro de carte et passe le test de Luhn est un signe plus fort que des données de paiement pourraient être exposées. Cette règle combine la détection de motifs à une validation réelle.

Configurations CORS risquées. Le scanner cherche des combinaisons dangereuses. Une origine wildcard :

Access-Control-Allow-Origin: *

avec les identifiants autorisés :

Access-Control-Allow-Credentials: true

Cela justifie une enquête. Il détecte également les serveurs qui semblent renvoyer le Origin de la requête sans une validation adéquate.

Rendre le scanner accessible par l’IA

Le Model Context Protocol est une méthode standard permettant aux applications d’IA d’utiliser des outils et des données externes. Plutôt que de se limiter à un scanner indépendant, le projet le met à disposition en tant qu’outil appelable par l’IA. Le serveur MCP publie un outil :

secscan_scan_har

Un client d’IA fournit un fichier HAR, exécute le scanner et reçoit des résultats structurés en retour. Le flux est le suivant :

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

Il n’est plus nécessaire de lire un rapport ligne par ligne, car on peut simplement poser des questions aux résultats. Les questions typiques portent sur les constats les plus graves, ce qui est lié à l’authentification ou pourquoi une configuration CORS particulière est risquée. Le scanner fournit les preuves, et l’IA aide à les expliquer.

Éviter que l’IA ne prenne la décision d’acceptation/refus

L’IA est efficace pour expliquer les constats, résumer les résultats, aider à analyser les preuves, proposer des solutions et répondre aux questions relatives à un scan. Cependant, un déploiement en production ne devrait pas dépendre du fait qu’un modèle pense qu’un élément est vulnérable. C’est pourquoi le projet dispose également d’une barrière de sécurité CLI déterministe :

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

Lorsque des résultats critiques apparaissent, l’analyseur peut faire échouer la compilation. Cela ouvre deux voies distinctes. La première est une analyse assistée par l’IA :

AI-Assisted Analysis

HAR
 ↓
MCP
 ↓
AI
 ↓
Explain / Investigate / Triage

Le deuxième est une porte de sécurité déterministe :

Deterministic Security Gate

HAR
 ↓
Scanner
 ↓
Critical Finding?
 ↓
FAIL BUILD

La séparation est importante. Utilisez l’IA là où le raisonnement et l’interaction ajoutent de la valeur, et utilisez des règles déterministes lorsque les décisions de réussite/échec doivent être prévisibles.

L’intégration dans un pipeline Playwright

Considérez un job CI Playwright existant avec son étape de test habituelle :

- name: Run Playwright tests
  run: npx playwright test

Ajoutez une étape de sécurité juste après :

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

Les mêmes tests de qualité produisent désormais deux types de preuves : fonctionnelles et de sécurité. Le flux de travail global ressemble alors à ceci :

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

C’est l’aspect le plus attrayant de cette idée. Un flux de travail de sécurité distinct n’est pas toujours nécessaire pour chaque signal de base, car certaines vérifications peuvent se faire naturellement au sein du pipeline de contrôle qualité existant.

La question de conception difficile

Rédiger le serveur MCP n’a pas été la partie difficile. Ce qui l’a été, c’est de décider comment structurer les données entre le parseur HAR et les règles de sécurité. HAR est un format détaillé, et si chaque règle doit le comprendre directement, la maintenance devient très complexe rapidement. Une représentation intermédiaire résout ce problème :

HAR
 │
 ▼
Parser
 │
 ▼
Transaction
 │
 ▼
Security Rules

Les règles ne se soucient pas de l’endroit d’où provient une transaction. Elles reçoivent quelque chose qu’elles comprennent déjà, ce qui facilite l’extension du scanner.

Ce qui pourrait suivre

Il s’agit d’une première version, avec beaucoup de marge de progression. Les vérifications envisagées incluent :

• Analyse de la politique de sécurité du contenu
• X-Content-Type-Options et Referrer-Policy
• Problèmes liés à Cache-Control
• Exposition de JWT
• Faiblesses en matière d’authentification et de sessions
• Exposition de données sensibles
• Plus de vérifications CORS
• Signaux liés à l’autorisation

Les constatations pourraient également comporter des preuves plus détaillées, présentées de cette manière :

Finding
Severity
Rule
Evidence
Request
Response
Impact
Remediation

La couche MCP pourrait éventuellement répondre à des questions telles que « Quelles anomalies doivent être examinées en premier ? », « Plusieurs anomalies sont-elles causées par le même problème de configuration ? » et « Expliquez cette anomalie à un développeur. »

L’intégration avec CI est une autre direction : GitHub Actions, commentaires de sécurité sur les demandes de fusion, sortie SARIF, seuils de gravité, anomalies de référence et détection des régressions de sécurité. L’objectif est que les tests de sécurité soient perçus comme un autre contrôle de qualité et non comme un domaine distinct.

Pourquoi les spécialistes du QA sont bien placés

Une grande partie du travail quotidien des ingénieurs QA fait également partie intégrante de la sécurité des applications : HTTP, API, authentification et autorisation, automatisation des tests, CI/CD, analyse du comportement et des pannes des applications. La création d’outils permet d’approfondir les connaissances bien au-delà de ce que peuvent offrir seuls des cours ou des certificats. Un projet de ce type aborde successivement l’analyse des fichiers HAR, la sécurité HTTP, les cookies, CORS, la détection des données secrètes et sensibles, les règles de sécurité, MCP, les contrôles CLI et CI/CD.

Les avantages vont au-delà d’un simple dépôt supplémentaire : il montre comment les données d’automatisation QA peuvent se transformer en intelligence en matière de sécurité. Les tests surveillent déjà le comportement des applications, les fichiers HAR le enregistrent de manière structurée, les règles extraient des signaux utiles du trafic, et MCP permet aux clients basés sur l’IA d’accéder à ces fonctionnalités. Ensemble, ils forment une idée globale unifiée :

QA Automation
      +
Application Security
      +
AI
      +
DevSecOps

Le point essentiel est que les tests de sécurité n’ont pas besoin de commencer par une autre analyse. Ils peuvent débuter avec les tests de trafic déjà effectués. L’automatisation des tests de qualité, la sécurité des applications, l’intelligence artificielle et DevSecOps combinés offrent peut-être plus d’avenir et couvrent un plus large éventail de domaines que chacun d’eux pris isolément.