Перетворення трафіку Playwright HAR на результати перевірки безпеки за допомогою сканера MCP

Інженери з тестування щодня працюють з API, запитами HTTP, процесами входу, автоматизацією браузерів, конвеєрами CI/CD та поведінкою додатків. Це сильно перетинається з питаннями безпеки додатків, що ставить запитання: чи можуть трафіки автоматизованих тестів вже слугувати вхідними даними для тестування безпеки?

Однією з відповідей є сервер MCP (Model Context Protocol), який сканує записаний трафік тестів на наявність проблем з безпекою. Конвеєр є простим: запустити автоматизацію тестування, зафіксувати HTTP-трафік, просканувати його на проблеми та дозволити ШІ допомогти у інтерпретації результатів. Важливо те, що сканер ніколи не надсилає додаткові запити до додатку.

Два світи, які ділять одне джерело даних

Безпека та контроль якості зазвичай розглядаються як окремі процеси. У рамках контролю якості виконуються завдання з написання тестів, їх запуску, перевірки функціональності та підготовки звітів. Робота з безпекою відбувається окремо: використання інструментів безпеки, сканування додатку, дослідження вразливостей та повідомлення про знайдені проблеми.

Проте автоматизовані тести вже взаємодіють із додатком. Вони викликають API, надсилають заголовки автентифікації та куки, отримують відповіді та звертаються до кінцевих точок. Усе це є трафіком HTTP, який може слугувати джерелом сигналів щодо безпеки.

Файли HAR як місток

Інструменти на кшталт Playwright можуть зберігати мережеву діяльність браузера у вигляді файлу HAR (HTTP Archive). Кожна операція HTTP у цьому файлі містить деталі, зокрема:

• URL-адреси запитів та методи HTTP
• Заголовки запитів та відповідей
• Куки
• Тіла запитів та відповідей
• Коди стану та інші метадані

Це створює конвеєр, який починається з автоматизації контролю якості та закінчується скануванням трафіку, який він створив:

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

Не створюється жоден новий потік трафіку. Сканер аналізує те, що вже було зафіксовано під час тестів, що робить цей підхід пасивним.

Архітектура

Сканер — це інструмент на TypeScript, який читає файли HAR та шукає сигнали, пов’язані з безпекою. Його структура навмисно проста:

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

Одним із ключових рішень у проектуванні було розділення парсера HAR, нормалізованої моделі транзакцій, правил безпеки та двигуна сканування на окремі частини. Лише парсер працює з форматом HAR. Правила ніколи не бачать початкової структури HAR та працюють з нормалізованими транзакціями, тому додавання нового правила пізніше є простим.

Перевірки у першій версії

Відсутній HSTS. Сканер позначає відповіді, які не містять цього заголовка:

Strict-Transport-Security

HSTS змушує браузери вимагати використання HTTPS, і це є важливою частиною безпечної конфігурації.

Звичайний HTTP. Запити, надіслані через

http://

замість

https://

вказує на випадково небезпечні кінцеві точки, які з’являються під час звичайних тестових запусків.

Атрибути cookie. У cookie перевіряються захисні позначки:

Secure
HttpOnly
SameSite

Куку для автентифікації чи сеансу, яка не має потрібних атрибутів, заслуговує на увагу.

Значення, схожі на секрети, у відповідях. Уявіть собі відповідь на кшталт:

{
  "apiKey": "..."
}

Значення, схоже на облікові дані, яке повертається клієнту, є потенційною проблемою. Це особливо цікаво, оскільки тестування якості може випадково на нього натрапити, без необхідності написання спеціального тесту безпеки для цієї мети.

Чутливі параметри URL. Іноді секрети потрапляють у URL:

/api/user?token=...

Сканер перевіряє URL-адреси на наявність імен параметрів та шаблонів, які можуть вважатися конфіденційними. URL-адреси потрапляють у журнали, історію браузера, проксі, системи аналітики та інші місця, тому це має значення.

Номери платіжних карток. Це було одне з найцікавіших правил. Сканер виявляє значення, схожі на номери карток, та перевіряє їх за допомогою алгоритму Луна. Випадковий 16-значний номер мало що говорить, але значення, яке схоже на номер картки і пройшло перевірку за алгоритмом Луна, є більш явним ознакою того, що дані про оплату можуть бути викриті. Це правило поєднує виявлення шаблонів із реальною перевіркою.

Ризиковані налаштування CORS. Сканер шукає небезпечні комбінації. Наприклад, використання „дикого карандаша“ для вказання походження даних:

Access-Control-Allow-Origin: *

разом із дозволеними обліковими даними:

Access-Control-Allow-Credentials: true

Це вимагає розслідування. Він також виявляє сервери, які, схоже, віддзеркалюють значення Origin запиту без належної перевірки.

Робимо сканер доступним для виклику штучним інтелектом

Model Context Protocol — це стандартний спосіб для додатків штучного інтелекту використовувати зовнішні інструменти та дані. Замість того, щоб залишатися окремим сканером, проект робить його інструментом, який можна викликати штучним інтелектом. Сервер MCP публікує один такий інструмент:

secscan_scan_har

Клієнт ШІ надає файл HAR, запускає сканер та отримує структуровані результати. Процес виглядає так:

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

Читання звіту рядок за рядком більше не є єдиним варіантом, адже людина може просто поставити запитання до отриманих результатів. Типовими запитаннями можуть бути: які знахідки є найбільш серйозними за ступенем загрози, що пов’язано з процесом автентифікації чи чому певна налаштування CORS є ризикованою. Сканер надає докази, а ШІ допомагає їх пояснити.

Утримання ШІ поза процесом прийняття рішень про успіх/невдачу

ШІ добре справляється з поясненням знахідок, узагальненням результатів, допомогою у аналізі доказів, пропозиціями щодо усунення проблем та відповідями на запитання щодо сканування. Однак робоче впровадження не повинно залежати від того, чи вважає модель щось вразливим. Тому у проекті також є детерміністичний захисний механізм CLI:

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

Коли з’являються критичні результати, сканер може зіпсувати процес створення. Це відкриває два окремі шляхи. Перший — аналіз за допомогою ШІ:

AI-Assisted Analysis

HAR
 ↓
MCP
 ↓
AI
 ↓
Explain / Investigate / Triage

Другий — це детерміністичний брандмауер безпеки:

Deterministic Security Gate

HAR
 ↓
Scanner
 ↓
Critical Finding?
 ↓
FAIL BUILD

Розбіжність має значення. Використовуйте ШІ там, де міркування та взаємодія додають цінності, а також детерміністичні правила там, де рішення про успіх чи невдачу мають бути передбачуваними.

Інтеграція в конвеєр Playwright

Розгляньмо існуючу роботу Playwright CI з її звичайним кроком тестування:

- name: Run Playwright tests
  run: npx playwright test

Додайте крок безпеки відразу після нього:

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

Тепер одні й ті самі тести якості дають два типи доказів – функціональні та безпекові. Загальний процес роботи виглядає так:

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

Це найпривабливіший аспект цієї ідеї. Окремий процес безпеки не завжди необхідний для кожного базового сигналу, адже деякі перевірки можуть відбуватися природним чином у межах існуючої системи контролю якості.

Складне питання проектування

Написання сервера MCP не було складною частиною. Складно було вирішити, як структурувати дані між парсером HAR та правилами безпеки. HAR — це деталізований формат, і якщо кожне правило має розуміти його безпосередньо, технічне обслуговування швидко ускладнюється. Проміжна форма вирішує цю проблему:

HAR
 │
 ▼
Parser
 │
 ▼
Transaction
 │
 ▼
Security Rules

Правила не зважають на те, де походить транзакція. Вони отримують щось, що вже розуміють, що полегшує розширення сканера.

Що може бути далі

Це перша версія, яка має великий потенціал для розвитку. Кандидатські перевірки включають:

• Аналіз політики безпеки контенту
• X-Content-Type-Options та Referrer-Policy
• Проблеми з Cache-Control
• Витік JWT
• Слабкі місця автентифікації та сеансів
• Витік конфіденційних даних
• Більше перевірок CORS
• Сигнали, пов’язані з авторизацією

Результати також можуть містити більш детальні докази у такому форматі:

Finding
Severity
Rule
Evidence
Request
Response
Impact
Remediation

Шар MCP з часом може відповідати на запитання на кшталт "Які знахідки слід досліджувати спочатку?", "Чи кілька знахідок спричинені однією проблемою конфігурації?" та "Поясніть цю знахідку розробнику."

Ще одним напрямком є інтеграція з CI: GitHub Actions, коментарі щодо безпеки у запитах на підтягування коду, результати SARIF, пороги серйозності, базові знахідки та виявлення регресій у безпеці. Мета полягає у тому, щоб тестування безпеки відчувалося як ще один етап перевірки якості, а не як окремий процес.

Чому фахівці з QA знаходяться у вигідному положенні

Більша частина роботи інженерів з тестування щодня також є основою безпеки додатків: HTTP, API, автентифікація та авторизація, автоматизація тестів, CI/CD, аналіз поведінки та збоїв додатків. Створення інструменту дозволяє глибше зрозуміти ці аспекти, ніж це можливо лише за допомогою курсів чи сертифікатів. Такий проект по черзі охоплює парсинг файлів HAR, безпеку HTTP, куки, CORS, виявлення конфіденційних та секретних даних, правила безпеки, MCP, механізми CLI та процеси CI/CD.

Користь від цього виходить далеко за межі просто ще одного репозиторію: це демонструє, як дані автоматизації тестування можуть перетворитися на інформацію для забезпечення безпеки. Тести вже відстежують поведінку додатків, файли HAR записують її у структурованому вигляді, правила виділяють корисні сигнали з трафіку, а MCP дозволяє клієнтам на основі штучного інтелекту отримувати доступ до цих можливостей. Разом вони утворюють єдину концепцію:

QA Automation
      +
Application Security
      +
AI
      +
DevSecOps

Основний висновок полягає у тому, що тестування безпеки не обов’язково має починатися з чергового сканування. Воно може розпочатися з даних, які вже отримані під час тестування трафіку. Автоматизація тестування якості, безпека додатків, штучний інтелект та DevSecOps разом можуть принести більше перспектив та охопити більше аспектів, ніж будь-який з них окремо.

Пов’язані матеріали

• Практичні нотатки: Microsoft створив сервер Playwright MCP. Потім сказав вам це зробити — детальний огляд практичних нотаток: Microsoft створив сервер Playwright MCP. Потім сказав вам це зробити: контракти, перевірки та шаблони коду для команд, які використовують цю модель.

Практичні нотатки: „MCP: Протокол, який перетворює ШІ з чат-бота на агента ШІ“ — детальний огляд Практичних нотаток: „MCP: Протокол, який перетворює ШІ з чат-бота на агента ШІ“: контракти, перевірки та шаблони коду для команд, які розробляють системи MCP.

Забезпечення безпеки інструментів MCP із можливістю запису: сім рівнів захисту окрім токена — чому токен MCP не надає дозволу на запис даніх та як сім рівнів контролю, розділення облікових даних, схвалення точних запитів та правила повторних спроб забезпечують безпеку.

Практичні нотатки: 5 підключень MCP, які перетворюють Claude Code на начальника штабу — Детальний посібник з Практичних нотаток: 5 підключень MCP, які перетворюють Claude Code на начальника штабу: контракти, перевірки та шаблони коду для команд, які використовують цю схему.