Turning Playwright HAR Traffic into Security Findings with an MCP Scanner

QA engineers handle APIs, HTTP requests, login flows, browser automation, CI/CD pipelines and application behavior every day. That overlaps heavily with application security, which raises a question: could the traffic automated tests already produce double as input for security testing?

One answer is an MCP (Model Context Protocol) server that scans recorded test traffic for security issues. The pipeline is short: run QA automation, capture the HTTP traffic, scan that traffic for problems and let an AI help interpret the findings. The notable part is that the scanner never sends extra requests to the application.

Two worlds sharing one data source

Security and QA are usually treated as separate activities. The QA routine goes write tests, run tests, validate functionality, produce reports. Security work happens elsewhere: run security tools, scan the application, investigate vulnerabilities, report findings.

Yet automated tests already talk to the application. They call APIs, send authentication headers and cookies, receive responses and hit endpoints. All of that is HTTP traffic, and it can serve as a source of security signals.

HAR files as the bridge

Tools such as Playwright can save browser network activity as a HAR (HTTP Archive) file. Each HTTP transaction in it carries details including:

• Request URLs and HTTP methods
• Request and response headers
• Cookies
• Request and response bodies
• Status codes and other metadata

This yields a pipeline that starts with QA automation and ends with scanning the traffic it produced:

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

No fresh round of traffic gets generated. The scanner studies what the tests have already captured, which makes the approach passive.

Architecture

The scanner is a TypeScript tool that reads HAR files and looks for security-relevant signals. Its layout is deliberately plain:

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

A key design choice was splitting the HAR parser, a normalized transaction model, the security rules and the scan engine into separate parts. Only the parser deals with the HAR format. Rules never see the original HAR structure and work on normalized transactions instead, so adding a new rule later is easy.

Checks in the first version

Missing HSTS. The scanner flags responses lacking the header:

Strict-Transport-Security

HSTS makes browsers insist on HTTPS, and it's a meaningful part of secure configuration.

Plain HTTP. Requests made over

http://

rather than

https://

point to accidentally insecure endpoints that show up during ordinary test runs.

Cookie attributes. Cookies are checked for protective flags:

Secure
HttpOnly
SameSite

An authentication or session cookie missing the right attributes deserves a look.

Secret-like values in responses. Imagine a response such as:

{
  "apiKey": "..."
}

A credential-looking value returned to a client is a potential problem. It's especially interesting because a QA test can stumble on it naturally, with no dedicated security test written for the purpose.

Sensitive URL parameters. Secrets sometimes land in URLs:

/api/user?token=...

The scanner inspects URLs for parameter names and patterns that look sensitive. URLs end up in logs, browser history, proxies, analytics systems and other places, so this matters.

Payment card numbers. This was among the more interesting rules. The scanner spots values that look like card numbers and validates them with the Luhn algorithm. A random 16-digit number says little, but a value that resembles a card number and passes the Luhn check is a stronger sign that payment data may be exposed. The rule joins pattern detection with real validation.

Risky CORS setups. The scanner looks for dangerous combinations. A wildcard origin:

Access-Control-Allow-Origin: *

together with credentials allowed:

Access-Control-Allow-Credentials: true

warrants investigation. It also catches servers that appear to echo the request's Origin back without proper validation.

Making the scanner callable by AI

The Model Context Protocol is a standard way for AI applications to use external tools and data. Rather than stopping at a standalone scanner, the project exposes it as an AI-callable tool. The MCP server publishes one tool:

secscan_scan_har

An AI client supplies a HAR file, runs the scanner and gets structured findings back. The flow looks like this:

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

Reading a report line by line is no longer the only option, because a person can simply put questions to the results. Typical prompts would be which findings rank highest in severity, what's tied to authentication or why a particular CORS setup is risky. The scanner provides the evidence, and the AI helps explain it.

Keeping AI out of the pass/fail decision

AI is good at explaining findings, summarizing results, helping investigate evidence, suggesting remediation and answering questions about a scan. A production deployment shouldn't hinge on whether a model thinks something is vulnerable, though. So the project also has a deterministic CLI security gate:

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

When critical findings appear, the scanner can fail the build. That gives two separate paths. The first is AI-assisted analysis:

AI-Assisted Analysis

HAR
 ↓
MCP
 ↓
AI
 ↓
Explain / Investigate / Triage

The second is a deterministic security gate:

Deterministic Security Gate

HAR
 ↓
Scanner
 ↓
Critical Finding?
 ↓
FAIL BUILD

The split matters. Use AI where reasoning and interaction add value, and use deterministic rules where pass/fail decisions must be predictable.

Dropping it into a Playwright pipeline

Consider an existing Playwright CI job with its usual test step:

- name: Run Playwright tests
  run: npx playwright test

Add a security step right after it:

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

The same QA tests now yield two kinds of evidence, functional and security. The overall workflow then looks like this:

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

That's the most appealing aspect of the idea. A separate security workflow isn't always necessary for every basic signal, since some checks can happen naturally inside the existing QA pipeline.

The hard design question

Writing the MCP server wasn't the difficult part. Deciding how to structure data between the HAR parser and the security rules was. HAR is a detailed format, and if each rule has to understand it directly, maintenance gets hard fast. An intermediate representation solves that:

HAR
 │
 ▼
Parser
 │
 ▼
Transaction
 │
 ▼
Security Rules

Rules don't care where a transaction originated. They receive something they already understand, which makes the scanner easier to extend.

What could come next

This is a first version, with plenty of room to grow. Candidate checks include:

• Content Security Policy analysis
• X-Content-Type-Options and Referrer-Policy
• Cache-Control problems
• JWT exposure
• Authentication and session weaknesses
• Sensitive data exposure
• More CORS checks
• Authorization-related signals

Findings could also carry richer evidence, shaped like this:

Finding
Severity
Rule
Evidence
Request
Response
Impact
Remediation

The MCP layer might eventually answer questions like "Which findings should be investigated first?", "Are several findings caused by the same configuration issue?" and "Explain this finding to a developer."

CI integration is another direction: GitHub Actions, security comments on pull requests, SARIF output, severity thresholds, baseline findings and detection of security regressions. The goal is for security testing to feel like one more quality gate and not a separate world.

Why QA people are well placed

Much of what QA engineers do every day is also core to application security: HTTP, APIs, authn and authz, test automation, CI/CD, application behavior and failure analysis. Building a tool pushes understanding deeper than courses or certificates alone. A project of this kind covers HAR parsing, HTTP security, cookies, CORS, secret and sensitive-data detection, security rules, MCP, CLI gates and CI/CD, one after another.

The payoff goes beyond one more repo: it shows how QA automation data can turn into security intelligence. Tests already watch application behavior, HAR files record it in structured form, rules pull useful signals out of the traffic and MCP lets AI clients reach those capabilities. Together they form one combined idea:

QA Automation
      +
Application Security
      +
AI
      +
DevSecOps

The core takeaway is that security testing needn't begin with yet another scan. It can begin with the traffic tests already produce. QA automation, application security, AI and DevSecOps together may hold more promise, and cover more ground, than any one of them alone.