Your Application Has Role-Based Access Control. But What About the AWS Role Behind It?

Application teams usually think about broken access control as a user accessing another user's record, a standard user opening an administrator endpoint, or an API failing to validate resource ownership. But an application can enforce its own roles correctly while the AWS identity running the application remains dangerously overprivileged.

OWASP identifies Broken Access Control as A01 in the 2025 list. It includes least-privilege violations, privilege elevation, unauthorized information exposure, and users gaining capabilities beyond their intended authorization.

Broken access control is not only an application problem

There are really four distinct authorization layers to consider:

• Application authorization — what a signed-in user may do in the UI.
• Cloud identity authorization — what the AWS role running the code may do.
• Resource-based authorization — what a bucket, key or queue policy allows.
• Cross-account authorization — which external principals may assume in.

Consider an AWS Lambda function used by a healthcare application. The application may correctly prevent a receptionist from viewing administrative records. However, the Lambda execution role might hold:

s3:*
kms:Decrypt
secretsmanager:GetSecretValue
iam:PassRole
lambda:UpdateFunctionCode
Resource: *

An application flaw that initially exposes only one API endpoint could now provide a path to read every S3 bucket, retrieve application secrets, decrypt protected information, modify Lambda code, pass a more powerful role, and move from one compromised workload to broader AWS access. The initial problem is in the application. The resulting blast radius is determined by AWS IAM.

The hidden AWS permission chain

A single over-scoped execution role turns a contained bug into a route across the account:

Why individual policy reviews are insufficient

A role may not appear dangerous until several permissions are combined. Reviewed one at a time, each looks like routine administration:

iam:CreatePolicyVersion  +  iam:SetDefaultPolicyVersion

iam:PassRole  +  lambda:CreateFunction  +  lambda:InvokeFunction

The first pair lets an identity quietly promote an existing policy to a dangerous version. The second lets an identity deploy code under a role it was never granted directly.

How Securitain reconstructs effective access

Securitain examines the AWS authorization layer behind the application by:

• Inventorying IAM users, groups, roles, policies and access keys.
• Identifying wildcard actions and wildcard resources.
• Classifying sensitive permissions and resolving effective, inherited access.
• Considering permission boundaries and Service Control Policies.
• Detecting privilege-escalation paths and dangerous permission combinations.
• Analyzing external trusts and cross-account access.
• Calculating the blast radius associated with an identity.
• Providing evidence, affected resources and remediation guidance.

From finding to remediation

The output is a finding card a team can act on directly: