Your app is handing strangers AWS credentials
An over-permissive Amazon Cognito identity pool gives anyone with your public pool id working AWS credentials. No exploit, no stolen key. Here is the misconfiguration, and the only control that matters.
No exploit, no stolen key, and a stranger on the internet is reading your data. They used an id you put in your own app on purpose.
What it is
An Amazon Cognito identity pool hands temporary AWS credentials to authenticated and, if enabled, unauthenticated guest users by assuming IAM roles tied to the pool. The pool id is usually embedded in client-side applications, so it is effectively public. If the unauthenticated role, or an authenticated role, is over-permissive, anyone who calls the Cognito credentials APIs with that pool id gets working AWS credentials and can reach whatever the role allows, such as S3 buckets or DynamoDB tables. This is T1190 (exploit public-facing application) into T1078 (valid accounts).
Why it works
The pool id is meant to be in the client, so it is not a secret. With a public id, the IAM role is the only real control, and here it was set far too broad.
How to detect it
In CloudTrail, look for credential requests to the pool from many unknown or unauthenticated identities, followed by the pool’s role reaching backend resources it should not expose to guests.
The fix that holds
Least-privilege every identity-pool role, and disable unauthenticated access unless you truly need it. Use role trust conditions and per-identity policy variables so each user reaches only their own data, and audit all pools for broad roles. Rotating the pool id does nothing, because the new one will be public too.
Practice it
We built a Cognito identity-pool abuse scenario in GraphLattice Range so teams learn why the role, not the id, is the control, and what containment looks like.