2026-06-19 · 8 min
Middleware is the layer everyone forgets
Your gateways, brokers, and meshes route everything and appear in no threat model. A tour of the failures we keep finding.
Ask a team for their architecture diagram and you'll get boxes for services and arrows for traffic. The arrows are the interesting part. Every one of them passes through an API gateway, a message broker, or a service mesh — and in most threat models, those systems appear nowhere.
That gap is why we built Vectasec.
The layer that routes everything
Middleware is infrastructure's connective tissue. The gateway terminates TLS and decides who gets in. The broker holds every event your business emits, sometimes for weeks. The mesh decides which service may call which. Compromise any of these and you don't own one service — you own the conversation between all of them.
Yet the tooling attention goes elsewhere. Cloud posture tools stop at the AWS API. Code scanners stop at the repo. Runtime agents watch processes, not routing tables. The middleware config — thousands of lines of YAML that constitute your actual security policy — is audited by nobody, drifting quietly between environments.
What we keep finding
Running Vectasec against real estates, the same failures recur:
- Internal means unauthenticated. Routes marked internal skip auth entirely, one VPC peering away from being reachable.
- The wildcard ACL. A broker rule written during an incident three years ago, granting
*on a topic prefix that now includes payments events. - Staging is the exploit manual. The mesh policy that's strict in production is permissive in staging — same services, same data classifications, weaker rules.
- The dead-letter queue. Failed messages, complete with PII, parked unencrypted with broader read access than the source topic.
None of these are exotic. They are configuration, which means they are checkable — if anything bothers to check.
Auditing the seam without becoming one
A middleware security tool sits in a sensitive spot, so Vectasec follows the same rules as every ZHASK product: read-only credentials against gateway, broker, and mesh admin APIs; deployment inside your boundary; every finding backed by the configuration snapshot that produced it.
It also does the one thing static review can't: diffing. Environment against environment, declared policy against enforced policy, this week against last week. Drift is the middleware failure mode, and drift only shows up when someone is comparing.
The arrows on the diagram deserve the same scrutiny as the boxes. That's the whole thesis.