DEV Community: Shieldly

Securing S3 Bucket Policies: Public Access, Conditions, and Common Mistakes

Shieldly — Thu, 25 Jun 2026 12:24:23 +0000

Originally published at shieldly.io/blog.

S3 bucket policies are written once and forgotten. They survive team changes, architecture pivots, and migration projects — and they accumulate permissions that nobody intended to leave open. S3 misconfigurations have been behind some of the largest cloud data breaches on record.

Why S3 Bucket Policies Matter

Bucket policies are resource-based policies attached to the bucket itself. They can grant access to principals that have no IAM permissions at all — including anonymous callers — if the policy allows it. A single misconfigured statement can override months of careful IAM work.

The Three Most Dangerous Patterns

1. Principal: * with no condition

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

An unconditioned wildcard principal means any AWS account, any IAM entity, and any unauthenticated caller can invoke the allowed actions. On a public S3 endpoint this is the open internet.

Fix: Add a condition — aws:PrincipalOrgID, aws:SourceArn, or aws:PrincipalArn:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalOrgID": "o-yourorgid123"
    }
  }
}

2. Missing s3:SecureTransport condition

Without aws:SecureTransport: true, the policy permits access over unencrypted HTTP. Credentials and data travel in plaintext. Add this to every Allow statement:

"Condition": {
  "Bool": {
    "aws:SecureTransport": "true"
  }
}

3. Overly broad Action grants

"Action": "s3:*"

s3:* includes s3:DeleteObject, s3:PutBucketPolicy, and s3:DeleteBucket. A policy intended to share read access becomes a full-control grant. Replace with the exact actions needed:

"Action": ["s3:GetObject"]

S3 Block Public Access Interaction

Block Public Access (BPA) settings at the account and bucket level override bucket policies. But they only block policies that grant access to Principal: * — a policy granting access to a specific external account bypasses BPA entirely. BPA is not a substitute for correct bucket policy authoring.

What a Secure Bucket Policy Looks Like

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/my-app-role"
      },
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "Bool": { "aws:SecureTransport": "true" }
      }
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
      "Condition": {
        "Bool": { "aws:SecureTransport": "false" }
      }
    }
  ]
}

Explicit principal, scoped actions, HTTPS enforced, deny-on-HTTP for belt-and-suspenders.

Analyze S3 bucket policies automatically — paste into Shieldly's free AI-Powered analysis. No signup, no credit card.

Launch offer: code 90Off2M — 90% off first 2 months. Pro from $1.90/mo. shieldly.io/pricing

Catching Risky IAM in CloudFormation Templates Before You Deploy

Shieldly — Thu, 25 Jun 2026 12:23:09 +0000

Originally published at shieldly.io/blog.

Most IAM security conversations center on the AWS console or raw JSON policy documents. But a significant share of production IAM misconfigurations originates in CloudFormation templates. By the time a CF stack is deployed, the IAM roles and policies inside it are live — and unless you reviewed the template before running cdk deploy or aws cloudformation create-stack, you may not have noticed what you just granted.

Why CloudFormation IAM Risk Is Different

In a CloudFormation template, IAM roles are buried alongside compute resources, storage buckets, and networking config. Reviewers focused on architecture often skim past the Properties.Policies block on a Lambda execution role.

A single CloudFormation template may create five roles, two managed policy attachments, and three inline policies — all in a single deploy. The blast radius of an overly-permissive role is multiplied by every resource that role is attached to.

The Most Common CF IAM Mistakes

AdministratorAccess on Lambda execution roles. Tempting during development. In production it grants Action: * on Resource: * to every invocation:

# DO NOT SHIP THIS
Type: AWS::IAM::Role
Properties:
  ManagedPolicyArns:
    - arn:aws:iam::aws:policy/AdministratorAccess

Action: * in inline policies. Inline policies defined inside an AWS::IAM::Role resource are easy to overlook:

Policies:
  - PolicyName: InlinePolicy
    PolicyDocument:
      Statement:
        - Effect: Allow
          Action: "*"       # Admin access, probably unintentional
          Resource: "*"

Missing permission boundaries on auto-created roles. Without a boundary, any policy attached to the role later is unconstrained.

Wildcard Resource on DynamoDB and S3. Scoping actions correctly but leaving Resource: *:

Statement:
  - Effect: Allow
    Action:
      - dynamodb:GetItem
      - dynamodb:PutItem
    Resource: "*"   # applies to every table in the account

Fix: replace with the specific table ARN.

How CDK Makes It Easier to Slip Up

CDK provides escape hatches — addToRolePolicy, addOverride, raw PolicyStatement objects — that let developers bypass guardrails. A single escape-hatch call can inject an Action: * statement into an otherwise well-scoped role, and nothing in the CDK build output will flag it.

Catching It Before Deploy

1. Analyze the synthesized template. cdk synth produces the CloudFormation JSON/YAML. Analyze that output before any deploy command runs.

2. Policy review gates in CI. Add a template analysis step to your CI pipeline that runs on every PR touching infrastructure files. Fail the pipeline on HIGH or CRITICAL IAM findings.

# .github/workflows/shieldly.yml
- name: Analyze CloudFormation IAM
  uses: shieldly-io/action@v1
  with:
    paths: cdk.out/**/*.template.json
    fail-on-severity: HIGH
  env:
    SHIELDLY_API_KEY: ${{ secrets.SHIELDLY_API_KEY }}

Analyze CF templates automatically — paste a template into Shieldly's free AI-Powered analysis. No signup, no credit card.

Launch offer: code 90Off2M — 90% off first 2 months. Pro from $1.90/mo. shieldly.io/pricing

AWS IAM NotAction vs Deny: The Misread Statement That Grants Everything

Shieldly — Thu, 25 Jun 2026 11:57:10 +0000

Originally published at shieldly.io/blog.

NotAction is one of the most misunderstood IAM elements. Its name suggests denial but it does not deny anything. When paired with Effect: Allow, it grants access to every action in all of AWS except the ones you listed.

What NotAction Actually Means

NotAction inverts the Action element. Instead of listing what a statement covers, you list what it excludes — and the statement covers everything else.

{
  "Effect": "Allow",
  "NotAction": ["iam:*", "sts:*"],
  "Resource": "*"
}

This allows every action across every AWS service except IAM and STS. That includes s3:DeleteObject, ec2:RunInstances, rds:CreateDBSnapshot, lambda:InvokeFunction, and everything else. The author almost certainly meant to restrict IAM access — they accidentally granted everything else.

The One Legitimate Use Case

NotAction with Effect: Deny is the one safe pattern. It is commonly used in Service Control Policies to create a "deny all except break-glass" control:

{
  "Effect": "Deny",
  "NotAction": [
    "iam:CreateLoginProfile",
    "sts:AssumeRole"
  ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:PrincipalArn": "arn:aws:iam::123456789012:role/BreakGlassRole"
    }
  }
}

This denies everything except the listed break-glass actions, for everyone except the break-glass role.

How to Rewrite the Dangerous Pattern

If you wrote NotAction + Effect: Allow trying to deny specific actions, replace it:

Instead of this (grants everything except IAM):

{
  "Effect": "Allow",
  "NotAction": "iam:*",
  "Resource": "*"
}

Write this (allows only what you need):

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-bucket/*"
}

Then add an explicit Deny for anything you want blocked:

{
  "Effect": "Deny",
  "Action": "iam:*",
  "Resource": "*"
}

Effect: Deny with an explicit action list is not the same as NotAction Allow — the former creates a hard deny, the latter creates a broad allow. They are opposite things.

Catch IAM statement mistakes automatically — paste a policy into Shieldly's free AI-Powered analysis. No signup, no credit card.

Launch offer: code 90Off2M — 90% off first 2 months. Pro from $1.90/mo. shieldly.io/pricing