Cross-Origin Resource Sharing (CORS)

CORS (Cross-Origin Resource Sharing) policy in AWS is a mechanism that allows web applications running on one domain to access resources hosted on a different domain, while enforcing necessary security restrictions. AWS implements CORS in several services, most commonly in Amazon S3 and API Gateway, enabling controlled cross-origin communication between clients and AWS-hosted resources.[1][2][3]

Core Concepts

CORS builds on the browser’s same-origin policy, which by default restricts web applications from making requests across domains for security reasons. CORS is an extension that lets developers specify, via a configuration document, which external origins are permitted to access resources, what methods (like GET, PUT, POST) can be used, and which headers can be exchanged during such requests.[2][1]

Example Use Cases

• A frontend web application served from one S3 bucket accesses data or uploads files to another S3 bucket via AJAX using CORS.[3][2]
• An API hosted by API Gateway enables CORS so a client web app on another domain can fetch or submit data safely.[6]

Configuring CORS in AWS Services

• Amazon S3: You add a CORS configuration in JSON format to specify allowed origins, HTTP methods, headers, and exposed headers. This configuration must explicitly list the domains and methods permitted to interact with the bucket. For example:

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET",
            "PUT",
            "POST",
            "DELETE",
            "HEAD"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": [
            "ETag",
            "x-amz-server-side-encryption",
            "x-amz-request-id",
            "x-amz-id-2"
        ],
        "MaxAgeSeconds": 3000
    }
]

This allows any origin and several HTTP methods, but can be restricted as needed for security.[4][3]

• API Gateway: Enabling CORS is often a one-click process in the AWS Console, which adds the necessary HTTP headers. For more custom setups, you may need to configure the OPTIONS method and manually set the required headers for all relevant responses.[6]

Security and Best Practices

While CORS enables richer client-side applications, it should be carefully configured to avoid unintended access. For example, allowed origins and methods should be as restrictive as possible, and wildcards (“*”) should only be used for public, non-sensitive resources. Standard bucket policies and IAM roles continue to apply alongside CORS; enabling CORS does not change your access controls, but instead layers browser-specific permissions on top.[2][3]

1 2 3 4 5 6 7 8