A claim-check pipeline stores customer documents in a shared object storage bucket and passes references through a queue. What access-control mistakes commonly show up here, and how should read access to the payload actually be scoped?

## Two authorization surfaces Splitting a payload from its notification message introduces a second place where access control has to be correctly configured, and the most common security mistake in claim-check implementations is assuming that securing the message on the broker also secures the payload in storage, when in fact the two are entirely separate authorization surfaces that must each be locked down deliberately. A team can carefully restrict who can subscribe to a queue or topic -- `IAM` policies, VPC endpoints, encryption on the wire -- and still leave the underlying object storage bucket configured with broad read access to any authenticated principal in the account, or in the worst misconfigurations, public read access, because the storage bucket was set up separately, possibly by a different team, without anyone connecting its access policy to the sensitivity of what claim-check pipelines were about to start writing into it. ## Why a permissive bucket defeats a locked-down broker The core problem this creates is that the reference in the claim check message -- an object key or URL -- is often, by itself, sufficient to fetch the payload if the bucket's access policy is permissive. This means that anything with visibility into the reference can retrieve the full payload regardless of how carefully the broker side was locked down, whether that is: - an authorized consumer; - a misconfigured logging pipeline that happens to capture message bodies; - or an attacker who has compromised any service with broad bucket read access. For a pipeline moving customer documents, medical records, or financial data, this is a materially different risk profile than a plaintext payload sent inline through a broker whose access is already tightly scoped, because the storage side effectively becomes a second, independently-configured front door to the same sensitive data. ## Scoping access narrowly and briefly The standard mitigation is to scope access to the payload as narrowly and briefly as possible, rather than granting broad standing access to the bucket. Two mechanisms do most of the work here. 1. **Least-privilege IAM.** First, consumers should hold roles or service accounts permitted to read only the specific bucket, or better, only the specific prefix or path pattern their pipeline actually uses, never a blanket read-all-buckets or read-all-objects grant, and definitely not long-lived static access keys embedded in configuration. 2. **A pre-signed URL.** Second, and often stronger for claim-check specifically, is generating a short-lived, pre-signed URL or a time-limited, single-object-scoped credential at the point the producer writes the payload, and putting that URL (rather than a bare object key requiring separate standing permissions) into the claim check message itself. A pre-signed URL grants access to exactly one object for a bounded window -- minutes to a few hours, tuned to how quickly consumers are expected to process the message -- after which it stops working entirely, meaning that even if the message or its contents leak somewhere unintended, the exposure window is bounded and doesn't grant ongoing access to the bucket at large. ## Encryption and audit logging Encryption is table stakes on both sides of this pattern and worth naming explicitly rather than assuming: - **At rest:** payloads in the object store should be encrypted, ideally with a key management setup where access to decrypt is also scoped per-consumer rather than a single shared key that, once compromised, decrypts everything ever written to the bucket. - **In transit:** the fetch itself should happen over `TLS`, same as the broker connection. For particularly sensitive payloads it's also worth having independent audit logging on the storage side -- most object stores can log every read request with the identity that made it -- because the broker's own delivery logs only show that a small reference message was delivered, not that the actual payload was subsequently read, by whom, or how many times; without object-level access logs, a compromised consumer or a leaked pre-signed URL being used repeatedly could go unnoticed. ## The two designs, side by side A concrete example: a document-management pipeline processing signed contracts writes each PDF to a private `S3` bucket with default encryption enabled and bucket policies that deny all public access, then generates a pre-signed GET URL valid for fifteen minutes and embeds that URL, rather than the bare object key, in the claim check message published to `SQS`. A downstream OCR consumer picks up the message, fetches the PDF using the pre-signed URL within that window, and the URL simply stops granting access afterward regardless of whether the message or its contents end up logged, cached, or retained somewhere else in the pipeline by accident. Compare this to a naive implementation that puts a bare bucket-and-key pair in the message and relies on every consumer having a standing IAM role with read access to the whole bucket -- that design means every service holding that role, and every place the message ever transits or gets logged, becomes a durable, un-expiring path to every document ever written to the bucket, not just the one referenced in a given message.