Auditing Message Broker Topic Authorization

Auditing message-broker topic authorization: when a wildcard subscribes to everyone

A message broker is a shared channel that many producers and consumers, often many tenants, talk through, and topic authorization is what keeps one client's messages from reaching another's. That boundary is thinner than it looks. Authenticating to the broker is not the same as being authorized per topic: a broker that checks the connection but not the topic lets any authenticated client read or write any topic. Wildcards make it worse, a subscription with a wildcard can match another tenant's topics and receive their messages, and a broad publish permission can inject into a control or command topic that consumers act on. And on a shared broker, topic naming is frequently the only thing separating tenants, which is a convention, not an enforced boundary. The audit asks, for each client, exactly which topics it can publish to and subscribe to, and whether that matches its role. You audit this by enumerating effective topic permissions and testing cross-tenant reach.

When to use

• A broker (MQTT, Kafka, AMQP, or similar) carries messages across producer, consumer, or tenant boundaries.
• Clients authenticate to the broker but topic-level publish and subscribe authorization may be missing.
• Wildcard subscriptions or broad publish grants may cross topics or tenants on a shared broker.

Scope check

Test broker authorization only on brokers you own or are authorized to assess, on non-production topics. Subscribing or publishing exercises a live broker and can receive or inject real messages, so use non-production topics and never read another tenant's real messages or inject into a live command topic. If you can't name the authorization, stop.

The loop

1. Establish each client's intended topics first. Name, per client or tenant, exactly which topics it should publish to and which it should subscribe to. This is the false-positive killer: a client authorized to precisely its own topics for precisely the direction it needs, with no wildcard crossing tenants, is correctly scoped. Name the intended topic map, then compare effective permissions to it.

2. Confirm per-topic authorization exists. Determine whether the broker authorizes publish and subscribe per topic or merely authenticates the connection. A broker that admits any authenticated client to any topic has no topic boundary at all, so the first check is whether topic-level access control is enforced, not just connection authentication.

3. Enumerate wildcard and broad grants. For each client, read its publish and subscribe permissions and flag wildcards and broad prefixes. A wildcard subscription can match other tenants' topics and receive their messages; a broad publish grant can reach control, command, or other tenants' topics. Compute what each wildcard actually matches across the topic space, not what it was intended to match.

4. Check the direction of each grant. Confirm publish and subscribe are scoped separately and correctly: a consumer that only needs to read should not be able to publish, and a producer that only needs to write should not be able to subscribe to responses it should not see. A grant that conflates the two directions widens reach beyond the client's role.

5. Check tenant separation on a shared broker. Where tenants share a broker, determine whether topic naming is the only separation or whether per-tenant authorization enforces it. If naming is the boundary, test whether a client can publish or subscribe to another tenant's topic by naming it, since a naming convention without enforcement is not isolation.

6. Confirm and record. Confirm by subscribing to or publishing on a topic a client should not reach, a wildcard receiving another tenant's non-production message, or a publish into a control topic, without reading real messages or injecting into a live command path. Kill the lead if the broker enforces per-topic authorization, no wildcard or broad grant crosses tenants or reaches control topics, publish and subscribe are separately scoped, and tenant separation is enforced rather than by naming alone. Record the client source, the topic or queue sink, and the wildcard or missing per-topic authorization that admitted it.

Where topic authorization leaks

• Connection auth is not topic auth. A broker that authenticates the client but not the topic lets any connection read or write any topic.
• A wildcard subscription catches other tenants. A subscription wildcard that matches beyond the client's topics receives messages it was never meant to see.
• A broad publish grant reaches control topics. A wide publish permission injects into command or control topics that consumers act on.
• Publish and subscribe conflated widen reach. A grant that does not separate the two directions lets a producer read responses or a consumer inject messages.
• Naming is not isolation. On a shared broker, topic naming as the only tenant separation is a convention a client can step outside by naming another tenant's topic.

Worked example (a confirm and a kill)

Confirm. A shared MQTT broker authenticates clients but authorizes subscriptions loosely, and a tenant's client holds a wildcard subscription intended for its own device topics. The wildcard also matches another tenant's device topics under a shared prefix, so the client receives the other tenant's non-production telemetry, and a broad publish grant lets it publish into a command topic those devices act on. Confirmed cross-tenant reach via wildcard subscription and broad publish, high, remediation = enforce per-topic authorization scoped to each tenant's own topics, replace wildcards with explicit per-tenant topic grants, and separate publish and subscribe permissions so no client can inject into command topics it only consumes.

Kill. The broker authorizes every publish and subscribe per topic, each client is granted only its own tenant's topics with no wildcard that crosses tenants, publish and subscribe are scoped separately to the client's role, and tenant separation is enforced by authorization rather than topic naming. A client naming another tenant's topic is refused for both directions. Killed, kill_reason = "per-topic authorization enforced with no cross-tenant wildcard, publish and subscribe separately scoped, and enforced tenant separation; no client reaches a topic outside its role."

Rationalizations to reject

• "Clients authenticate to the broker." → Authentication is not per-topic authorization; confirm the broker checks the topic, or any authenticated client reads and writes any topic.
• "The wildcard is just for our topics." → Compute what the wildcard actually matches across the whole topic space; a shared prefix makes it catch other tenants.
• "They only consume, they cannot publish." → Confirm publish and subscribe are separately scoped; a conflated grant lets a consumer inject into command topics.
• "Tenants use their own topic names." → Naming is a convention, not a boundary; test whether a client can name and reach another tenant's topic.
• "It is an internal broker." → Internal brokers still carry cross-tenant and control messages; topic authorization is the boundary regardless of network placement.

Executing this in practice

You need each client's effective publish and subscribe permissions, whether the broker enforces per-topic authorization, what every wildcard actually matches, the separation of the two directions, and how tenants are separated. For each client, compare its effective topic reach to its role and test a cross-topic or cross-tenant access. Reading the broker's authorization rules shows the intended map; subscribing or publishing to a should-be-unreachable topic shows whether it holds.

Related

• auditing-observability-pipeline-collector-trust - telemetry often flows over a broker; unauthenticated ingestion and broad topic reach are the same trust gap at different points.
• auditing-namespace-as-tenant-boundary - the same tenant-separation-by-convention failure, here on broker topics instead of Kubernetes namespaces.
• auditing-serverless-event-source-trust - broker topics are event sources for consumers; whether the consumer trusts the message is the paired question.
• mapping-attack-surface - use it to enumerate the brokers, topics, and clients crossing trust boundaries before auditing each grant.
• FINDING-SCHEMA.md - source = the client publishing or subscribing, sink = the topic or queue it reaches, evidence = the wildcard or missing per-topic authorization that admitted it.