Troubleshoot S3 AccessDenied without making the bucket public

An application cannot read an S3 object and receives a 403 response. Disabling public-access protections would broaden exposure without necessarily fixing the application’s identity permissions.

Why this happens

Access depends on the requesting principal, requested action, resource policy and other applicable controls. Encryption permissions and explicit denies can also affect the request.

Step-by-step solution

1. Identify the principal actually making the request and the exact bucket, key and operation. Use request IDs and CloudTrail information where available.

2. Review the relevant identity and bucket policies, including explicit denies and cross-account requirements. For encrypted objects, inspect the applicable key permissions.

3. Grant only the required action on the intended resource through the normal infrastructure review process. Keep public-access protections unless public distribution is an intentional design.

Worked example

Reading an object needs the relevant object permission; listing a bucket is a separate operation. A user who can list names is not automatically allowed to download every object.

Verify the fix

Retry the exact operation as the application identity. Also check that an unrelated identity remains denied and that no broad public access was introduced.

Prevent a repeat

Keep bucket and key ownership documented, and test permissions with the deployed role rather than an administrator’s console session.

Reference

Official documentation or standards guidance

An original Gistmax troubleshooting guide. Scenarios and sample values are illustrative; configuration depends on your software version and environment. Cover diagram: Gistmax Tutorials.