Event-driven architecture has taken over modern backend systems. Instead of services calling each other directly, they emit events. Other services subscribe to those events and react. The result is a loosely coupled system where components can evolve independently, scale separately, and fail without cascading.
That decoupling is the main selling point. It is also the main security problem.
When Service A calls Service B directly, the security relationship is explicit. You can see it in the code, trace it in the network, and enforce it with authentication and authorization. When Service A emits an event that Service B, C, and D all consume, the security relationships are implicit, distributed, and much harder to govern.
The Trust Problem in Event Systems
In a synchronous architecture, trust flows along the call chain. The client authenticates to the API gateway, the gateway authenticates to the backend service, the backend service authenticates to the database. Each hop has an explicit trust boundary.
In an event-driven system, trust is mediated through the message broker. Service A trusts the broker. Service B trusts the broker. But Service A and Service B may have no direct trust relationship with each other. This raises immediate questions:
- Can Service A trust that events from the broker actually originated from a legitimate producer?
- Can Service B trust that no one has tampered with events in transit?
- Can the broker guarantee that events are delivered only to authorized consumers?
The answer to all three questions depends on how the broker is configured, and the default configuration for most message brokers prioritizes convenience over security.
Event Spoofing and Injection
If a malicious actor gains access to publish events on a topic, they can inject fraudulent events that downstream consumers will process as legitimate. Consider an e-commerce system where an OrderPlaced event triggers inventory adjustment, payment processing, and shipping. A spoofed OrderPlaced event could trigger all of these processes.
Event spoofing is possible when:
- Broker authentication is weak or absent: Many message broker deployments use no authentication for internal services
- Topic authorization is too broad: Services have publish permission on topics they should only be able to read
- Event validation is missing: Consumers accept any event on a subscribed topic without validating the producer identity or event integrity
Mitigations include:
- mTLS for broker connections: Authenticate every producer and consumer
- Topic-level ACLs: Grant minimum necessary permissions -- most services should only publish to their own topics and consume from specific others
- Event signing: Include a cryptographic signature in each event that consumers can verify against the producing service's public key
- Schema validation: Reject events that do not conform to the expected schema
Replay Attacks
Events are often stored for replay -- it is one of the advantages of event sourcing. But that storage creates a replay attack surface. If an attacker can trigger the replay of historical events, they can cause duplicate processing.
Consider financial events. A Payment.Processed event that gets replayed could trigger a second payment. A Refund.Issued event that gets replayed could issue a second refund.
Defenses against replay attacks include:
- Idempotent consumers: Design every consumer to handle duplicate events safely. This is good practice regardless of security concerns but becomes critical when adversaries might deliberately trigger replays.
- Event timestamps and sequence numbers: Consumers should reject events that are too old or out of sequence.
- Deduplication at the broker level: Some brokers support exactly-once semantics that prevent duplicate delivery, though the guarantees vary.
Data Leakage Through Events
Events often carry data. An OrderPlaced event might include customer name, address, email, and payment information. A UserUpdated event might include personal details. When these events flow through a central broker, that broker becomes a single point of data exposure.
Anyone with read access to the relevant topics can see all the data in every event. This is a problem because:
- Events persist: Unlike HTTP requests that are transient, events in systems like Kafka are stored on disk for days, weeks, or indefinitely
- Broad consumption patterns: Events are typically consumed by multiple services, expanding the blast radius of a data breach
- Limited field-level access control: Most brokers do not support filtering event fields based on consumer identity
Mitigations include event encryption (encrypt sensitive fields within events), claim-check patterns (store sensitive data separately and include only a reference in the event), and topic segmentation (separate sensitive and non-sensitive events into different topics with different access controls).
Schema Poisoning
Event schemas define the structure of events. In many systems, schemas are managed through a schema registry (like Confluent Schema Registry for Kafka). If an attacker can modify schemas in the registry, they can:
- Add fields that cause consumers to leak data in error messages
- Change field types to trigger deserialization errors that crash consumers
- Remove required fields to cause validation failures across the system
Schema registries need their own access controls, versioning policies, and change approval processes. Treat schema changes like code changes: review them, test them, and control who can make them.
Dead Letter Queues as Data Sinks
Events that fail processing are typically routed to dead letter queues (DLQs) for later analysis. These DLQs accumulate events that, by definition, could not be processed normally. They often receive less security attention than the main event topics.
But DLQs contain the same sensitive data as the events they originate from. And because they accumulate failures, they can contain events with unusual payloads -- including events crafted by attackers that intentionally triggered processing errors. DLQs need the same access controls, encryption, and monitoring as production event topics.
Monitoring Event-Driven Systems
Security monitoring for event-driven systems requires different approaches than monitoring synchronous APIs:
- Producer anomaly detection: Monitor for unexpected producers on topics, unusual event volumes, and events that fail schema validation
- Consumer lag monitoring: A consumer that falls behind may be under attack or may have been compromised
- Cross-service correlation: Trace events from production through consumption to detect manipulation or unauthorized access
How Safeguard.sh Helps
Safeguard maps the dependency relationships in your event-driven architecture, tracking the message broker clients, serialization libraries, schema registry integrations, and framework dependencies that power your event pipelines. When a vulnerability is found in a Kafka client library, an Avro serialization package, or any component of your event infrastructure, Safeguard identifies every affected service and helps you remediate before an attacker exploits the gap. Full SBOM visibility across your event-driven systems means no component goes untracked.