CORS configuration in AWS - Cheat Sheet & Quick Revision

Recall & Review

beginner

What does CORS stand for and why is it important in web applications?

CORS stands for Cross-Origin Resource Sharing. It allows web browsers to securely request resources from a different domain than the one that served the web page, enabling safe sharing of resources across origins.

beginner

In AWS S3, how do you enable CORS for a bucket?

You enable CORS by adding a CORS configuration XML to the S3 bucket settings. This configuration specifies allowed origins, methods, headers, and max age for requests.

beginner

What is the purpose of the AllowedOrigins element in a CORS configuration?

AllowedOrigins defines which domains are permitted to access the resources. It can be a specific domain or a wildcard (*) to allow all origins.

intermediate

Why should you avoid using a wildcard (*) in AllowedOrigins in production?

Using a wildcard allows any website to access your resources, which can lead to security risks. It's safer to specify only trusted domains.

beginner

What HTTP methods are commonly allowed in CORS configurations for AWS S3?

Commonly allowed methods include GET, PUT, POST, DELETE, and HEAD, depending on the operations your application needs.

Which AWS service commonly uses CORS configuration to control cross-origin requests?

A Amazon EC2

B Amazon S3

C AWS Lambda

D Amazon RDS

Amazon S3 uses CORS configuration to allow or restrict cross-origin requests to buckets.

In a CORS configuration, what does the AllowedHeaders element specify?

A How long the response can be cached

B Which HTTP methods are allowed

C Which domains can access the resource

D Which HTTP headers can be sent with the request

AllowedHeaders specifies which HTTP headers the browser can include in the actual request.

What is the effect of setting AllowedOrigins to "*" in an S3 CORS policy?

A Allows any origin to access the bucket resources

B Blocks all cross-origin requests

C Allows only the origin of the bucket owner

D Requires authentication for all requests

Setting AllowedOrigins to "*" means any website can make cross-origin requests to the bucket.

Which HTTP method is NOT typically included in an S3 CORS configuration?

A PATCH

B POST

C GET

D DELETE

PATCH is not commonly used in S3 CORS configurations; GET, POST, and DELETE are typical.

What does the MaxAgeSeconds setting control in a CORS configuration?

A How long the resource is available

B The timeout for the HTTP request

C How long the browser caches the preflight response

D The maximum size of the request body

MaxAgeSeconds controls how long the browser can cache the preflight OPTIONS request response.

Explain how to configure CORS for an AWS S3 bucket to allow a specific website to access its resources.

Think about the JSON structure that controls origins, methods, and headers.

Describe why CORS is necessary and what security risks it helps to manage.

Consider how browsers protect users and how CORS fits in.

Practice

1. What does CORS stand for and why is it important in AWS S3 bucket configuration?

easy

A. Cross-Origin Resource Sharing; it controls access to resources from different websites.

B. Cloud-Origin Resource Security; it encrypts data in S3 buckets.

C. Cross-Object Resource Sync; it syncs files between buckets.

D. Cloud-Origin Resource Sharing; it manages AWS user permissions.

Solution

1. Step 1: Understand the acronym CORS

   CORS stands for Cross-Origin Resource Sharing, a web security feature.

2. Step 2: Identify its role in AWS S3

   CORS controls which websites can access resources in an S3 bucket, preventing unauthorized cross-site requests.

3. Final Answer:

   Cross-Origin Resource Sharing; it controls access to resources from different websites. -> Option A

4. Quick Check:

   CORS = Cross-Origin Resource Sharing [OK]

Hint: Remember CORS controls cross-site resource access [OK]

Common Mistakes:

• Confusing CORS with encryption or syncing
• Thinking CORS manages AWS user permissions
• Assuming CORS is only for AWS internal use

2. Which of the following is the correct JSON snippet to allow GET and POST methods from any origin in an S3 bucket CORS configuration?

easy

A. { "CORSRules": [{ "AllowedOrigins": ["http://example.com"], "AllowedMethods": ["PUT"] }] }

B. { "CORSRules": [{ "AllowedOrigins": ["*"], "AllowedMethods": ["DELETE"] }] }

C. { "CORSRules": [{ "AllowedOrigins": ["*"], "AllowedMethods": ["GET", "POST"] }] }

D. { "CORSRules": [{ "AllowedOrigins": ["*"], "AllowedMethods": ["PATCH"] }] }

Solution

1. Step 1: Identify AllowedOrigins and AllowedMethods

   The question asks for allowing any origin (*) and methods GET and POST.

2. Step 2: Match JSON snippet to requirements

   { "CORSRules": [{ "AllowedOrigins": ["*"], "AllowedMethods": ["GET", "POST"] }] } correctly sets AllowedOrigins to ["*"] and AllowedMethods to ["GET", "POST"].

3. Final Answer:

   { "CORSRules": [{ "AllowedOrigins": ["*"], "AllowedMethods": ["GET", "POST"] }] } -> Option C

4. Quick Check:

   AllowedOrigins=* and AllowedMethods=GET,POST [OK]

Hint: Look for AllowedOrigins '*' and methods GET, POST [OK]

Common Mistakes:

• Using wrong HTTP methods like DELETE or PATCH
• Setting AllowedOrigins to a specific domain instead of '*'
• Incorrect JSON structure or missing brackets

3. Given this CORS configuration snippet for an S3 bucket:

{
  "CORSRules": [
    {
      "AllowedOrigins": ["https://example.com"],
      "AllowedMethods": ["GET"],
      "AllowedHeaders": ["*"],
      "MaxAgeSeconds": 3000
    }
  ]
}

What will happen if a browser from https://example.com sends a POST request to this bucket?

medium

A. The POST request will succeed because MaxAgeSeconds is set.

B. The POST request will succeed because AllowedHeaders is '*'.

C. The POST request will be redirected to GET automatically.

D. The POST request will be blocked due to method not allowed.

Solution

1. Step 1: Check AllowedMethods in CORS configuration

   Only GET method is allowed from https://example.com.

2. Step 2: Understand effect on POST request

   POST is not in AllowedMethods, so the browser will block the request due to CORS policy.

3. Final Answer:

   The POST request will be blocked due to method not allowed. -> Option D

4. Quick Check:

   AllowedMethods=GET only, POST blocked [OK]

Hint: AllowedMethods must include the request method [OK]

Common Mistakes:

• Confusing AllowedHeaders with AllowedMethods
• Thinking MaxAgeSeconds affects allowed methods
• Assuming POST auto-converts to GET

4. You configured this CORS rule on your S3 bucket but your web app still gets CORS errors when making PUT requests from https://myapp.com:

{
  "CORSRules": [
    {
      "AllowedOrigins": ["https://myapp.com"],
      "AllowedMethods": ["GET", "POST"],
      "AllowedHeaders": ["*"]
    }
  ]
}

What is the most likely cause of the error?

medium

A. PUT method is not included in AllowedMethods.

B. AllowedOrigins should be '*', not a specific domain.

C. AllowedHeaders cannot be '*'.

D. CORSRules must include MaxAgeSeconds.

Solution

1. Step 1: Review AllowedMethods for PUT requests

   PUT is not listed in AllowedMethods, only GET and POST are allowed.

2. Step 2: Understand CORS behavior for unsupported methods

   Requests with methods not allowed by CORS are blocked by browsers.

3. Final Answer:

   PUT method is not included in AllowedMethods. -> Option A

4. Quick Check:

   AllowedMethods missing PUT causes CORS error [OK]

Hint: Check AllowedMethods includes your HTTP method [OK]

Common Mistakes:

• Assuming AllowedOrigins must be '*' for CORS to work
• Thinking AllowedHeaders '*' is invalid
• Believing MaxAgeSeconds is required

5. You want to configure an S3 bucket to allow only GET and OPTIONS requests from two specific domains: https://site1.com and https://site2.com. You also want browsers to cache the CORS response for 1 hour. Which is the correct CORS configuration JSON?

hard

A. {
"CORSRules": [
{
"AllowedOrigins": ["*"],
"AllowedMethods": ["GET", "OPTIONS"],
"AllowedHeaders": ["*"],
"MaxAgeSeconds": 3600
}
]
}

B. {
"CORSRules": [
{
"AllowedOrigins": ["https://site1.com", "https://site2.com"],
"AllowedMethods": ["GET", "OPTIONS"],
"AllowedHeaders": ["*"],
"MaxAgeSeconds": 3600
}
]
}

C. {
"CORSRules": [
{
"AllowedOrigins": ["https://site1.com"],
"AllowedMethods": ["GET"],
"AllowedHeaders": ["*"],
"MaxAgeSeconds": 3600
},
{
"AllowedOrigins": ["https://site2.com"],
"AllowedMethods": ["GET", "OPTIONS"],
"AllowedHeaders": ["*"],
"MaxAgeSeconds": 3600
}
]
}

D. {
"CORSRules": [
{
"AllowedOrigins": ["https://site1.com", "https://site2.com"],
"AllowedMethods": ["GET"],
"AllowedHeaders": ["*"],
"MaxAgeSeconds": 3600
}
]
}

Solution

1. Step 1: Check AllowedOrigins for both domains

   { "CORSRules": [ { "AllowedOrigins": ["https://site1.com", "https://site2.com"], "AllowedMethods": ["GET", "OPTIONS"], "AllowedHeaders": ["*"], "MaxAgeSeconds": 3600 } ] } correctly lists both https://site1.com and https://site2.com in AllowedOrigins.

2. Step 2: Verify AllowedMethods and MaxAgeSeconds

   { "CORSRules": [ { "AllowedOrigins": ["https://site1.com", "https://site2.com"], "AllowedMethods": ["GET", "OPTIONS"], "AllowedHeaders": ["*"], "MaxAgeSeconds": 3600 } ] } allows GET and OPTIONS methods and sets MaxAgeSeconds to 3600 (1 hour), matching requirements.

3. Final Answer:

   { "CORSRules": [ { "AllowedOrigins": ["https://site1.com", "https://site2.com"], "AllowedMethods": ["GET", "OPTIONS"], "AllowedHeaders": ["*"], "MaxAgeSeconds": 3600 } ] } -> Option B

4. Quick Check:

   AllowedOrigins two domains, methods GET & OPTIONS, cache 3600s [OK]

Hint: List all domains in AllowedOrigins and set MaxAgeSeconds for caching [OK]

Common Mistakes:

• Using '*' for AllowedOrigins when only specific domains are needed
• Missing OPTIONS method which browsers send for CORS preflight
• Splitting domains into multiple rules unnecessarily