Introduction

A 403 Forbidden from CloudFront means the request reached CloudFront, but CloudFront refused or could not obtain the content successfully. The cause is usually one of a small set of configuration problems: origin permissions, signed URL rules, alternate-domain mismatches, WAF or geo restrictions, or a request path that does not map to an accessible object.

Start by Identifying Where the 403 Comes From

The first question is whether CloudFront itself is denying the request, or whether the origin is returning a 403 and CloudFront is forwarding it.

Typical sources include:

• S3 origin access not configured correctly
• signed URL or signed cookie mismatch
• AWS WAF blocking the request
• geo restriction on the distribution
• custom origin denying the path
• default root object or object key mismatch

The fix depends on which layer is actually rejecting the request.

S3 Origin Permissions Are the Most Common Cause

If CloudFront fronts a private S3 bucket, CloudFront needs permission to read objects from that bucket. The modern way to do this is Origin Access Control, often abbreviated OAC. Older setups may use Origin Access Identity, or OAI.

A bucket policy for OAC commonly looks like this:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Sid": "AllowCloudFrontRead",
6      "Effect": "Allow",
7      "Principal": {
8        "Service": "cloudfront.amazonaws.com"
9      },
10      "Action": "s3:GetObject",
11      "Resource": "arn:aws:s3:::my-private-bucket/*",
12      "Condition": {
13        "StringEquals": {
14          "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E123ABC456XYZ"
15        }
16      }
17    }
18  ]
19}

If this policy is missing or points at the wrong distribution, CloudFront cannot fetch the object and viewers see a 403.

Check the Object Key and Default Root Object

A missing object can sometimes surface as a 403 depending on the origin configuration. Verify the exact key, including case sensitivity.

Also check the distribution's default root object. If users browse / and the distribution expects index.html, a bad or missing root-object configuration can look like a permissions problem.

Signed URLs and Cookies

If the behavior requires signed URLs or signed cookies, any of the following can cause a 403:

• expired signature
• wrong key pair or trusted signer configuration
• policy does not match the requested path
• clock skew in generated expiration times

So if a file works publicly but fails only through signed access, inspect the signature path first.

Alternate Domain Names and TLS

If you request content through a custom domain, make sure:

• the host name is listed as an alternate domain name on the distribution
• the certificate attached to CloudFront covers that host
• DNS points at the correct distribution

A mismatch here often causes confusing failures that look unrelated to permissions.

WAF and Geo Restrictions

CloudFront can return 403 if AWS WAF blocks the request or if the distribution restricts viewer geography.

If some users can load the file and others cannot, this is a strong signal that origin permissions are not the only issue.

Debugging Steps

A practical workflow is:

1. test the object directly at the origin if appropriate
2. inspect the CloudFront behavior settings for auth and path patterns
3. confirm S3 bucket policy or custom origin access rules
4. check whether WAF or geo restriction is enabled
5. review CloudFront standard or real-time logs if available

For S3-backed origins, also verify that you are using the correct origin type. S3 REST endpoints and S3 website endpoints behave differently.

A Useful AWS CLI Check

If you suspect the object itself is missing or inaccessible in S3, check it directly.

aws s3api head-object --bucket my-private-bucket --key assets/app.js

If that fails for a principal that should have access, fix the bucket-side problem first.

Common Pitfalls

A common mistake is making the bucket private without granting CloudFront read access through OAC or OAI.

Another mistake is debugging only the viewer URL while ignoring path case sensitivity or an incorrect default root object.

Developers also often forget that signed URL and WAF failures produce the same status code as origin-permission problems, even though the fixes are completely different.

Summary

• CloudFront 403 errors usually come from origin permissions, signed access rules, WAF, geo restrictions, or path mismatches.
• For private S3 origins, verify OAC or legacy OAI configuration and bucket policy.
• Check the exact object key and any default root object setting.
• Signed URLs, custom domains, and WAF rules can all independently trigger 403 responses.
• Identify which layer is denying the request before changing policies blindly.