Amazon S3 CORS Configuration and Cross-Origin Requests – SAP-C02 Study Guide

Purpose of This Lesson

Amazon S3 Cross-Origin Resource Sharing (CORS) controls whether browser-based applications loaded from one origin can make requests to an S3 resource hosted at another origin.

CORS is primarily a browser security mechanism. It becomes relevant when a web application hosted at one domain needs to access objects in a different S3 bucket or S3 endpoint.

Key Concepts

What Is an Origin?

A browser origin is determined by three values:

• Scheme or protocol, such as http or https
• Hostname, such as www.example.com
• Port, such as 80 or 443

A change to any of these values produces a different origin. For example, these are distinct origins:

• http://mycompany.com
• https://mycompany.com
• http://www.mycompany.com
• http://mycompany.com:8080

A subdomain is not automatically treated as the same origin as its parent domain. For example, www.mycompany.com and mycompany.com must be considered separately when defining allowed origins.

Why S3 CORS Is Needed

Consider this architecture:

1. A browser loads a web application from an S3 static website endpoint representing www.mycompany.com.
2. JavaScript in that application requests web fonts or other objects from a second S3 bucket.
3. The browser detects that the request crosses from one origin to another.
4. The browser checks whether the destination allows the request through its CORS configuration.

Without an appropriate CORS rule on the destination bucket, the browser can block the cross-origin request even if the object is otherwise available to the application.

CORS does not make an object public and does not replace IAM or S3 bucket policies. It tells a compliant browser which cross-origin requests are permitted.

Preflight Requests

For some cross-origin requests, the browser sends a preflight request before sending the actual request. The preflight checks whether the destination permits the requested operation, headers, and origin.

The S3 CORS configuration can specify rules for:

• Allowed origins: Which origins may make browser requests
• Allowed methods: Which HTTP methods are permitted, such as GET, PUT, POST, or DELETE
• Allowed headers: Which request headers the browser may send

A rule does not necessarily need to specify every available setting, but it must allow the characteristics required by the application request.

Where CORS Is Configured

The CORS configuration is applied to the destination S3 bucket—the bucket receiving the browser request—not the bucket hosting the web application that initiated the request.

This is a common exam distinction:

• Source bucket or website: Hosts the application and establishes the requesting origin
• Destination bucket: Hosts the assets and must allow the cross-origin request through its CORS rules

Example CORS Rule

An S3 CORS configuration can contain rules such as:

[
  {
    "AllowedHeaders": ["*"],
    "AllowedMethods": ["PUT", "POST", "DELETE"],
    "AllowedOrigins": ["https://www.mycompany.com"]
  }
]

This rule permits requests from exactly https://www.mycompany.com using the listed methods and request headers.

The origin must match the browser’s actual origin. Allowing www.mycompany.com does not automatically allow mycompany.com, and allowing an HTTP origin does not automatically allow the HTTPS version.

Architecture Decision Guide

Requirement	S3 CORS consideration
A browser application reads objects from another S3 bucket	Configure CORS on the bucket containing the objects
The request uses GET	Include GET in AllowedMethods
The browser sends custom request headers	Permit the required headers in AllowedHeaders
Requests should come only from a known website	Specify the exact scheme, hostname, and port in AllowedOrigins
The application uses multiple domains	Add each required origin or use an appropriate controlled pattern
An object must be accessible to users	Configure authentication and authorization separately; CORS alone does not grant access

Exam-Relevant Takeaways

• CORS governs browser requests between different origins.
• An origin consists of the protocol, hostname, and port.
• http and https are different origins.
• A root domain and its subdomain are different origins.
• CORS configuration belongs on the S3 bucket being accessed.
• Allowed origins, methods, and headers are defined in S3 CORS rules.
• A preflight request may occur before the browser sends the actual request.
• CORS is not an authorization mechanism. IAM policies, bucket policies, presigned URLs, or other access controls still determine whether the request is authorized.

Common Exam Traps

Configuring CORS on the Hosting Bucket

If a website in Bucket A requests an object from Bucket B, the CORS rule generally belongs on Bucket B. The destination must indicate that it accepts requests from the application’s origin.

Treating Similar Hostnames as the Same Origin

mycompany.com and www.mycompany.com are not interchangeable for CORS purposes. The configured origin must match the browser’s origin.

Ignoring the Protocol or Port

These are different origins:

• http://app.example.com
• https://app.example.com
• https://app.example.com:8443

A rule must allow the version actually used by the application.

Assuming CORS Grants S3 Permissions

CORS only controls whether the browser permits the response to be exposed to the requesting web application. It does not override a bucket policy, IAM policy, object ownership setting, or other S3 access control.

Allowing the Wrong HTTP Method

A rule allowing GET does not automatically permit PUT, POST, or DELETE. The required method must be included in the CORS rule.

Real-World Engineer Notes

• Prefer specific allowed origins when the set of trusted web applications is known. Broad wildcard settings can expose responses to unintended web origins.
• Validate the complete origin, including scheme and port, when troubleshooting browser errors.
• Inspect browser developer tools to identify whether the failure involves a preflight request, an unsupported method, a missing header permission, or an S3 authorization failure.
• Distinguish browser behavior from server-to-server behavior. CORS is enforced by browsers; non-browser clients do not generally rely on browser CORS enforcement.
• A successful CORS configuration still requires the requesting client to have a valid way to access the object, such as public access where appropriate, IAM-based access, or a presigned URL.

Quick Reference Summary

• CORS: Browser control for cross-origin requests.
• Origin: Protocol + hostname + port.
• Configured on: The destination S3 bucket.
• Main rule properties: Allowed origins, methods, and headers.
• Preflight: Browser check performed before certain cross-origin requests.
• Not provided by CORS: Authentication or authorization.
• Important matching rule: http, https, root domains, subdomains, and different ports are distinct origins.

Flashcards

1. What does CORS control?

Whether a browser permits a web application from one origin to make requests to another origin.

1. What three values define an origin?

Protocol, hostname, and port.

1. Are mycompany.com and www.mycompany.com the same origin?

No. They are different hostnames and must be allowed separately if both are required.

1. Where is an S3 CORS configuration applied when one bucket’s website accesses another bucket?

On the destination bucket containing the requested objects.

1. What does AllowedMethods specify?

The HTTP methods that cross-origin browser requests may use.

1. What does AllowedOrigins specify?

The web origins permitted to make cross-origin requests.

1. What does AllowedHeaders specify?

The request headers that the browser may send in the cross-origin request.

1. What is a preflight request?

A browser-issued preliminary request that checks whether the destination permits the intended cross-origin request.

1. Does CORS grant permission to read a private S3 object?

No. S3 authorization must separately allow access.

1. Are HTTP and HTTPS the same origin?

No. The protocol is part of the origin.

Practice Questions

Question 1

A static website is hosted in an S3 bucket at https://app.example.com. JavaScript from the website must retrieve JSON objects from a second S3 bucket. The objects are accessible to the requesting identity, but the browser blocks the request. Where should the CORS configuration be applied?

A. On the bucket hosting the static website
B. On the bucket containing the JSON objects
C. In IAM only
D. In Route 53

Correct answer: B

The second bucket is the destination of the browser request. Its CORS configuration must allow requests from https://app.example.com. IAM or bucket policies still control authorization separately.

Question 2

An application is served from https://www.example.com, but the S3 CORS rule allows only http://www.example.com. The browser rejects the request. What is the most likely cause?

A. The S3 bucket must use versioning
B. HTTPS and HTTP represent different origins
C. CORS applies only to POST requests
D. The destination bucket must be in the same Region as the website

Correct answer: B

The protocol is part of an origin. An HTTPS request is not covered by a rule that allows only the HTTP origin.

Question 3

A browser application needs to send PUT requests with a custom Authorization header to an S3 bucket. Which CORS configuration is required?

A. Allow the application’s origin, include PUT, and allow the required request header
B. Allow only GET and make the object public
C. Configure CORS on the browser’s local machine
D. Enable S3 Transfer Acceleration

Correct answer: A

The destination bucket must allow the exact origin, the PUT method, and the headers used by the browser request. Authorization to access the object remains a separate concern.

Question 4

A CORS rule allows https://app.example.com and the GET method. A browser request from https://admin.example.com fails even though both names belong to the same company. Why?

A. S3 does not support multiple websites
B. CORS compares the exact requesting origin; a different subdomain is a different origin
C. CORS requires both sites to use the same port 80
D. S3 permits only requests from the root domain

Correct answer: B

app.example.com and admin.example.com are different origins. The destination bucket must explicitly allow every required origin.