← All posts

Are your protocols covered?

Aug 4, 2026 api-security protocols websocket graphql grpc soap mcp scanning

Every API scanner on the market covers REST. That is table stakes, and it is also where most protocol coverage ends. Your APIs are already speaking five others — GraphQL, gRPC, SOAP, WebSocket, and MCP — and a scan that only sends payloads at REST is reporting on a fraction of your attack surface while the report says "clean."

This is not a niche gap. Postman's 2025 State of the API report puts REST at 93% of respondents, but also WebSockets at 35% and GraphQL at 33% — a third of teams are shipping each, on top of REST, not instead of it. Multi-protocol is the normal case now.

We went through the public documentation of every point-in-time scanner we could find, commercial and free, asking one narrow question: does it actively test each protocol as part of an automated scan? REST, always. GraphQL and SOAP, usually. gRPC, occasionally. MCP, rarely. WebSocket, almost never.

This page is not a scoreboard — we're not naming anyone. It is the set of questions we used to sort a real yes from a qualified one, written so you can put them to any vendor, including us, and get an answer that survives contact with a real target.

Why one tool, not six

The realistic alternative to full-protocol coverage is not "no coverage." It is a stack: the DAST for REST, a manual proxy for the WebSocket, a bespoke harness for gRPC, a separate CLI for MCP. That stack has costs that never show up on any feature grid.

  • Nothing runs unattended. Manual tooling is excellent when a human is driving it. It does not run at 2am on every merge, which is when coverage actually has to happen.
  • Severity is not comparable across tools. Six scoring models, six false-positive rates, six definitions of "high." Nobody can rank the week's findings without re-triaging all of them by hand.
  • The gaps live between the tools. A session authenticated over REST and then escalated over a WebSocket is invisible to two scanners that each saw half of it.
  • Six procurement cycles, six renewals, six agents on the build box.

One engine, one auth context, one severity scale, one report. That is the argument for breadth in a single app — not that breadth is impressive, but that the seams between tools are where findings go missing.

The buyer's guide: eleven questions

Ask these of every vendor on your shortlist. Ask them of us. The useful answer to each is a specific mechanism, not a yes.

Coverage vs. discovery

1. For each of the six protocols, does the scanner send payloads, or does it list the endpoint? "Supports gRPC and SOAP" very often means the inventory layer recognises the endpoint and adds it to a list. Nothing is ever sent at it. Ask which of the two is happening, per protocol.

2. Is the coverage in the scanner, or in a manual tool that ships alongside it? This is the WebSocket pattern almost everywhere: first-class interception, breakpoints and manual fuzzing in a proxy, and no active scanner for WebSocket messages. Both are real capabilities. Only one of them runs in CI. Ask specifically: is this protocol a scan target in an unattended run?

3. Which of these is a paid add-on, a separate CLI, or a different SKU from the product I'm buying? Coverage that lives in another tool from the same vendor is still a second tool for you to run, wire up, and triage.

Depth

4. For GraphQL — does it test object-returning fields, or only scalars? Injection through a field that returns an object requires building a valid selection set so the resolver actually executes. Scanners that skip that step miss the resolvers that touch a database.

5. For gRPC — does it fuzz per field, and where does the schema come from? Server reflection, or a supplied .proto? And does it check transport security — a server that demands a client certificate but accepts an untrusted self-signed one is a broken mutual-TLS control that no payload will find.

6. For SOAP — does it read operation shapes from the WSDL and test per parameter? Per-parameter SQLi, XPath and command injection, in-band XXE, verbose-fault disclosure. A single generic request at the endpoint is not a SOAP test.

7. For WebSocket — does it authenticate, hold state, and fuzz per message? This is the question with the widest gap between how common the protocol is and how often it is scanned. The numbers:

  • 35% of teams report using WebSockets in Postman's 2025 State of the API survey — the same order as GraphQL, which almost every scanner covers.
  • ~11.6% of all Chrome page loads open a WebSocket, per Chrome's own platform use counters (1 August 2026) — up from ~8.6% in mid-2019. Roughly one page in nine, and climbing.
  • Over 99% browser support, unchanged since 2011. There is no compatibility reason left for a product not to use one.

And the traffic on that connection is the interesting half: WebSockets carry the authenticated, stateful side of most chat, trading, collaboration, live-dashboard and AI-streaming products — post-login, long-lived, and frequently reaching the same resolvers and queries as the REST API in front of it. So ask about subprotocol enumeration, payloads sent as frames on a live authenticated connection, Cross-Site WebSocket Hijacking, and missing Origin validation.

8. For MCP — does the scanner point at MCP servers, or expose itself as one? Most "MCP support" is the second thing: the scanner runs as an MCP server so an AI assistant can drive it. That is a control-plane convenience, not coverage. (We ship that too, and it isn't what we mean by MCP coverage below.)

9. For MCP again — static metadata analysis, or payloads through tools/call? Reading tool descriptions and judging them for poisoning and rug pulls is real value. It is also static analysis of text. Ask whether the scanner completes the handshake, enumerates tools, and drives payloads through the tools themselves — and whether it tests session isolation with concurrent calls.

Evidence

10. Where does the answer come from — documentation, or a run against a known-vulnerable target? The only thing that converts any of this from claims into evidence is a bake-off on a multi-protocol target you control. Ask for one. A vendor whose documentation states plainly where its active scanner stops is giving you better information than a vendor whose documentation is silent.

11. What is the false-positive rate, and how is it measured? Breadth is one axis. A scanner that reaches six protocols and reports noise on all six has made your week worse. Ask how findings are validated before they are recorded.

How NewScan answers its own questions

All six protocols, one engine, one severity scale. Free, self-hosted tier — no license, no key, nothing leaving your network:

  • REST — full detection catalog.
  • GraphQL — introspection and schema-leak misconfigurations; injection through both scalar and object-returning fields, building a valid selection set so resolvers actually run; blind SSRF through URL-shaped arguments.
  • gRPC — per-field injection fuzzing of unary methods via reflection or a supplied .proto, plus a broken-mutual-TLS check (server demands a client cert, accepts an untrusted self-signed one).
  • SOAP — operation shapes read from the WSDL, then SQLi / XPath / command injection per parameter, in-band XXE, and verbose-fault disclosure.
  • WebSocket — authenticated, stateful, per-message fuzzing. Subprotocol enumeration (graphql-ws, mqtt, actioncable), then SSTI / SQLi / command / traversal payloads as frames, plus Cross-Site WebSocket Hijacking and missing-Origin-validation checks.
  • MCP — the OWASP MCP Top 10: tool poisoning and invisible-Unicode metadata, indirect prompt injection through tool output, secret exposure, context over-sharing, and a session-isolation test that fires concurrent tools/call to catch credential bleed between sessions.

On question 11: every finding is reproduced before it is recorded, and the benchmark floor is 100% recall with zero false positives against the vulnerable targets we test on. That is the number to hold us to.

The out-of-band arms — blind SSRF over GraphQL and gRPC, blind XXE and WS-Addressing SSRF over SOAP, blind command injection through MCP tools — need a collaborator reachable from the target, which is the one paid capability. Run the hosted one or self-host your own. Every OOB-marked check keeps an in-band arm, so the free tier never loses a protocol outright.

Limits worth stating

  • Documented capability is not measured catch rate. That cuts both ways, and it is why question 10 is on the list.
  • Protocol breadth is one axis. It is not detection depth, inventory management, or CI/CD ergonomics — all of which matter, and on some of which other tools are stronger.
  • This moves monthly. MCP coverage in particular is changing fast. Re-ask these questions at renewal.

Whichever scanner you run, the exercise is the same: establish which of the six protocols it actually sends payloads at, rather than which ones appear on a feature list.

Sources. Postman 2025 State of the API · Chrome Platform Status — WebSocket use counter · Can I use — WebSocket API · NewScan protocol detail: shipped detection catalog (newscan/static/data/detections.json).