1 min lesson
The misconfiguration classes to name on sight
Walk through how an SSRF vulnerability in a web app running on a cloud VM can escalate into stolen IAM credentials and name the single control that most directly breaks the chain.
Step 1 of 2
The misconfiguration classes to name on sightthese recur across every cloud
Wildcards in actions or resources (s3:* on *).
"Temporary" admin grants that became permanent.
Fix: scope to specific actions and ARNs; review with access analyzers that flag unused permissions.
Buckets open to the internet or to a wildcard principal.
Snapshots and AMIs shared publicly by accident.
Fix: block-public-access at the account level; default deny; alert on any policy that adds a public grant.
An SSRF in your app fetches the instance metadata service and reads the attached role's credentials.
This turns a web bug into cloud credential theft - the Capital One pattern.
Fix: enforce IMDSv2 (token-required), restrict egress and never give instances roles broader than they need.
Access keys checked into code or baked into images.
No rotation, no expiry, full reach if leaked.
Fix: workload identity / role assumption instead of static keys (next subsection).
The SSRF-to-credentials chain is the one interviewers love because it crosses the app-security and cloud-security boundary the role straddles. If you describe an SSRF and stop at "it can read internal URLs," you've missed the punchline: on a cloud instance with IMDSv1, that internal URL is 169.254.169.254 and the response is a usable IAM credential.