In an event-driven cloud workload, why is a queue message an untrusted entry point?

## The definition that does the work An **entry point** is any place where data crosses into the system from a source the system does not control. In a request-response design the entry points are obvious, because they are endpoints someone deliberately exposed. In an event-driven cloud design they are configuration: a function is bound to a queue, a topic, an object-created notification, a schedule or a stream, and from then on **anything that can produce that event can invoke that code with a payload of its choosing**. Nobody wrote a listener, nobody opened a port, and there is no request log that looks like an attack. That is exactly why these entry points get missed. The second half of the definition matters just as much: *from a source the system does not control*. The control is not the network, and it is not obscurity. It is the **resource policy on the event source**, plus whatever the producer had to prove to write there. If that policy is permissive, the event source is a public entry point that simply lacks a URL. ## Worked example: a claim that never passed intake An insurer runs intake in one account and adjudication in another. Intake accepts submissions, validates them, checks the policy is in force, and puts a message on a queue. The adjudication account consumes messages and approves payment. The team's mental model is a pipeline: adjudication trusts the message because intake produced it. Now suppose the queue's policy grants send permission broadly rather than to the intake role alone. An external principal who has learned the queue identifier - from a leaked configuration file, a support ticket, a former contractor, an error page - can put a well-formed message directly onto the queue. The threats that lands are: - **Spoofing** (violating authenticity): the message impersonates intake. The consumer has no way to tell the difference, because *being on the queue* was the whole proof of origin. - **Tampering** (violating integrity): fields the consumer trusts because intake supposedly set them - a validated flag, an approved amount, a policy identifier - are now attacker-chosen. - **Repudiation** (violating non-repudiation): a payment goes out with no intake record behind it. When someone reconstructs what happened, the audit trail says a claim was adjudicated and no submission exists. The asset at risk here is not only money, it is the truthfulness of the record. Notice what is *not* the problem. The queue is not leaking data, the network is not misconfigured, and no code has a memory-safety bug. The defect is entirely in where the trust was placed. ## Enumerating event entry points A repeatable pass over a serverless design: 1. **List every trigger binding.** For each compute unit, what can invoke it - a queue, a topic subscription, an object notification, a schedule, a stream, a direct call? 2. **For each one, ask who can produce that event.** Read the resource policy of the source, not the code of the consumer. The answer is a set of principals; write it on the diagram. 3. **Ask what the consumer assumes about the producer.** Any field it does not re-check is a field the producer set on its behalf. 4. **Ask whether the event can be replayed or duplicated.** Delivery is usually at-least-once, so a consumer that is not idempotent can be made to act twice by a replayed message. The fourth point is worth separating from trust: at-least-once delivery is a reliability property, not an attack, but it means *correct* behaviour under duplicates is already required, and an attacker who can send gets that lever for free. ## What actually fixes it - **Least-privilege resource policy on the source.** Name the producer role. This is the control that makes the event source non-public in the first place. - **Authorise in the consumer.** Treat the message as untrusted input: validate the schema and the values, and check the claim against state you own rather than accepting what the payload asserts. - **Carry provenance you can verify.** Correlate the message to a record that only the real producer could have created - for example, look up the intake record by its identifier and confirm its state, rather than believing the message's *validated* flag. - **Separate the identity of the producer from the fact of being on the queue.** *It arrived here, therefore it is ours* is the assumption being exploited. ## Where this generalises The same reasoning applies to an object-created event. If a bucket prefix accepts uploads through presigned URLs, the writer of that object is an **anonymous internet client** holding a URL, and the entire access control is that URL's scope and expiry. Anything the consuming function then does with the bytes - parse them, transcode them, feed them to a downstream step - is processing attacker-supplied input, even though no part of the picture looks like a web endpoint.