CORS (Cross-Origin Resource Sharing) configuration is essential when your web applications need to access resources in an S3 bucket from different domains. This guide explains how to properly configure CORS for various use cases.

Understanding CORS for S3 Buckets

Cross-Origin Resource Sharing (CORS) is a security feature implemented by browsers that restricts web pages from making requests to a different domain than the one that served the original page. When building web applications that interact with S3 buckets, proper CORS configuration is essential to allow these cross-origin requests.

Example CORS Configuration

Below is a comprehensive CORS configuration example that allows specific origins to perform PUT and POST operations while allowing any origin to perform GET operations:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>http://localhost:3000</AllowedOrigin>
    <AllowedOrigin>https://localhost:3000</AllowedOrigin>
    <AllowedOrigin>https://*.example.com</AllowedOrigin>
    <AllowedOrigin>http://staging.example.com</AllowedOrigin>
    <AllowedOrigin>https://staging.example.com</AllowedOrigin>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <ExposeHeader>x-amz-server-side-encryption</ExposeHeader>
    <ExposeHeader>x-amz-request-id</ExposeHeader>
    <ExposeHeader>x-amz-id-2</ExposeHeader>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>Authorization</AllowedHeader>
</CORSRule>
</CORSConfiguration>

Configuration Breakdown

Rule 1: Restricted Write Access

The first rule allows specific origins to make PUT and POST requests to the bucket:

• Allowed Origins: Development environments (localhost:3000), production domains (*.example.com), and staging environments (staging.example.com)
• Allowed Methods: PUT and POST operations for uploading files
• Exposed Headers: Important S3-specific headers that client applications might need to access:
  • x-amz-server-side-encryption: Information about server-side encryption
  • x-amz-request-id and x-amz-id-2: Request identifiers useful for troubleshooting
• Allowed Headers: All request headers are allowed (*)

Rule 2: Public Read Access

The second rule allows any origin to make GET requests:

• Allowed Origin: Any origin (*)
• Allowed Method: Only GET operations for downloading/viewing files
• Cache Duration: Responses can be cached for 3000 seconds (50 minutes)
• Allowed Headers: Only the Authorization header is allowed, enabling authenticated GET requests

Implementing This Configuration

To apply this CORS configuration to your S3 bucket:

1. Open the Amazon S3 console
2. Select your bucket and navigate to the “Permissions” tab
3. Scroll down to the “CORS configuration” section
4. Click “Edit” and paste the XML configuration
5. Click “Save changes”

Security Considerations

• Only allow specific origins that need to interact with your bucket
• Limit allowed methods to only those required by your application
• For production environments, avoid using wildcard origins (*) for write operations
• Regularly audit your CORS configuration as your application evolves