All Tools View Categories About Contact Privacy

S3 Bucket Policy Generator

Build an S3 bucket policy statement — principal, actions, bucket vs object scope, and an optional condition — with a real public-access check.

Runs entirely in your browser — your bucket name and account IDs never leave this page.
This statement grants access to anyone on the internet — the principal is "*" and no condition restricts it. Double-check this is intentional.
0
statements
0
allow
-
public access
-
structurally valid

  

About S3 Bucket Policy Generator

An S3 bucket policy is a resource-based policy: instead of attaching permissions to a user or role, it lives on the bucket itself and names who — the Principal — is allowed to do what. That inversion trips people up constantly, especially the difference between a bucket-level ARN (arn:aws:s3:::my-bucket, needed for actions like listing) and an object-level ARN (arn:aws:s3:::my-bucket/*, needed for reading or writing individual objects), and the fact that a principal of "*" with no restricting condition means the bucket, or the objects in it, are reachable by literally anyone on the internet. S3 Bucket Policy Generator is a focused form for building exactly this shape of policy correctly.

You pick a principal type — Everyone (the public wildcard), a specific AWS account, or a specific IAM role or user ARN — enter the bucket name, choose which common S3 actions to allow from checkboxes (s3:GetObject, s3:PutObject, s3:ListBucket), and decide whether the statement should apply to the bucket itself, to the objects inside it, or to both — which controls whether the generated Resource field is the bare bucket ARN, the bucket ARN with a trailing /*, or an array containing both. An optional condition lets you restrict access further, most commonly by source IP address, without leaving the specialized form.

The one piece of real logic beyond simple field assembly is the public-access check. After building the statement, the tool inspects the resolved Principal and Condition: if the principal resolves to the AWS-wide wildcard * and there is no condition block restricting it in any way, a prominent red warning banner appears above the JSON output, explaining plainly that this statement grants access to anyone on the internet with no restriction. This is not a static disclaimer printed regardless of input — it is computed from the actual statement you built, so scoping the principal to a specific account or role, or adding an IP restriction, makes the warning disappear because the underlying condition genuinely no longer holds. That mirrors, on a much smaller scale, the kind of check AWS's own S3 Block Public Access and Access Analyzer features perform, though this tool only inspects the single statement you are currently building — it does not evaluate a bucket's full existing policy, its Block Public Access settings, ACLs, or any cross-account access that other statements or IAM policies elsewhere might grant.

Once built, the same structural validator used across these tools runs against the assembled document — confirming Version is present, the statement has a recognized Effect, an Action, and either a Resource or the Principal that resource-based policies use in its place. That check, plus the public-access warning, is the full scope of what gets verified: nothing here calls the AWS API, checks whether the bucket actually exists, or accounts for other policies, ACLs, or account-level Block Public Access settings that would also affect real-world access.

The result is a ready-to-attach bucket policy JSON document, with stat cards summarizing the statement and a clear warning when the combination you built amounts to public access — built and checked entirely in your browser, with the bucket name and any account IDs you enter never leaving the page.

Features

  • Principal picker — Everyone (public), AWS account (root), or a specific IAM role/user ARN.
  • Bucket-level vs object-level vs both resource targeting, producing the correct ARN shape automatically.
  • Common S3 actions as checkboxes — GetObject, PutObject, ListBucket — pre-filled sensibly.
  • Real public-access check — a red warning banner appears only when the resolved principal is the wildcard and no condition restricts it.
  • Optional condition builder — operator, key and value, most commonly aws:SourceIp.
  • Structural validation on the assembled statement and document.
  • Pretty-printed JSON output with Copy and Download .json.
  • Sample bucket policy pre-fills a realistic public-read-with-IP-restriction example.
  • One-click clear.
  • 100% client-side — bucket names and account IDs never leave the page.

How to Use

  1. Enter the bucket name (without arn:aws:s3::: — just the name).
  2. Pick a principal type — Everyone, AWS account, or a specific role/user ARN — and fill in the ARN or account if needed.
  3. Select the actions to allow (GetObject, PutObject, ListBucket, or a mix).
  4. Choose what the statement applies to — the bucket itself, its objects, or both.
  5. Optionally add a condition, such as restricting by source IP.
  6. Click Build bucket policy — read the public-access warning if it appears, and check the stat cards.
  7. Copy or download the resulting JSON to attach to your bucket.

Examples

Example 1 — public static website read access. Principal Everyone, action s3:GetObject, applies to Objects, bucket my-site-assets, no condition — this is flagged with the public-access warning, appropriately, since it is intentionally public.

Example 2 — restricted public read by office IP. Same as above but with condition IpAddress / aws:SourceIp / 203.0.113.0/24 — the warning disappears because the wildcard principal is now scoped by a condition.

Example 3 — cross-account partner access. Principal type AWS account, value arn:aws:iam::111111111111:root, actions s3:GetObject and s3:ListBucket, applies to Both, bucket partner-data-exchange — produces a two-ARN Resource array covering the bucket and its objects.

Example 4 — single role write access. Principal type IAM role/user ARN, value arn:aws:iam::123456789012:role/ingest-role, action s3:PutObject, applies to Objects, bucket uploads-inbound — a tightly scoped, non-public statement.

Example 5 — accidental public write. Principal Everyone, action s3:PutObject, no condition — the warning banner appears, correctly flagging that anyone could upload objects into the bucket, which is worth stopping to reconsider before attaching.

Benefits

  • Gets bucket-vs-object ARNs right automatically — a common source of "access denied" or "too permissive" bugs.
  • Real, computed public-access warning, not a generic disclaimer.
  • Common actions one click away instead of remembering exact action names.
  • Structural validation catches missing Effect/Action/Resource before you attach the policy.
  • Copy or download straight into the S3 console or IaC.
  • Private — bucket names and account IDs never leave your browser.

Frequently Asked Questions

How does the public-bucket warning actually work?
It is a real check on the assembled statement, not a static disclaimer: the tool looks at whether the resolved <code>Principal</code> is the wildcard <code>*</code> (either directly, or as <code>{"AWS":"*"}</code>) and whether the statement has no <code>Condition</code> block at all. If both are true — public principal, no restricting condition — a red warning banner appears above the output. Adding any condition (an IP restriction, for example) or switching the principal away from "Everyone" clears the warning immediately.
What principal types are supported?
Everyone (the AWS-wide wildcard <code>*</code>, for a genuinely public bucket like static website hosting), an AWS account (rendered as <code>{"AWS":"arn:aws:iam::ACCOUNT:root"}</code> for account-wide access), or a specific IAM role/user ARN (rendered as <code>{"AWS":"<the ARN you enter>"}</code>).
What does "applies to" control?
It decides the shape of the Resource array. "Bucket itself" produces just <code>arn:aws:s3:::bucket</code> (needed for actions like <code>s3:ListBucket</code> or <code>s3:GetBucketLocation</code> that operate on the bucket, not its objects). "Objects" produces <code>arn:aws:s3:::bucket/*</code> (needed for <code>s3:GetObject</code>/<code>s3:PutObject</code>). "Both" includes both ARNs in the Resource array, which is the common choice when mixing bucket-level and object-level actions in one statement.
Does it check that my actions match the resource I picked?
No — it does not cross-check, for example, that <code>s3:ListBucket</code> only makes sense against the bucket ARN and not an object ARN. Choose actions and "applies to" together; the tool assembles whatever combination you specify.
What condition types are offered?
A single optional condition per statement: an operator (StringEquals, StringLike, IpAddress, Bool), a condition key (commonly <code>aws:SourceIp</code> to restrict by IP/CIDR, but any key can be entered), and a value. Leaving any of the three blank omits the condition.
Does this validate against AWS's live S3 bucket policy grammar?
No. It runs the same structural check as the other tools here (Version present, Statement non-empty, each statement has a valid Effect, an Action, and a Resource or Principal) plus the public-access check described above — it does not call any AWS API or check bucket policy size limits.
Can I build a policy with multiple statements, like public read plus a restricted write?
This tool builds one statement per bucket policy submission, matching the common single-purpose bucket policy pattern. For a multi-statement bucket policy, build each statement here, copy its JSON, and combine the <code>Statement</code> arrays by hand, or use the general-purpose IAM Policy JSON Generator, which supports adding multiple statements before building the document.
Is the bucket name or account ID sent anywhere?
No. Everything — principal assembly, resource ARN construction, the public-access check, and validation — runs locally in your browser.
What actions are pre-filled?
The common S3 access actions <code>s3:GetObject</code>, <code>s3:PutObject</code> and <code>s3:ListBucket</code> are offered as checkboxes so a typical read/write bucket policy needs no typing, but you can select any combination.
Can I export the result?
Yes — Copy as JSON and Download .json buttons appear once a policy is built.