CORS configuration in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding CORS behavior in AWS S3

You have an AWS S3 bucket with the following CORS configuration:

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

What will happen if a web page hosted on https://anotherdomain.com tries to make a GET request to this bucket?

A The request will be redirected to https://example.com automatically.

B The request will succeed because GET is allowed for all origins.

C The request will succeed but only if the request includes credentials.

D The request will be blocked by the browser due to CORS policy.

💡 Hint

Check which origins are allowed in the CORS configuration.

The CORS configuration only allows requests from https://example.com. Requests from https://anotherdomain.com are blocked by the browser.

❓ Configuration

intermediate

Correct CORS configuration for multiple methods

You want to configure an AWS S3 bucket to allow cross-origin requests from https://myapp.com for GET, PUT, and DELETE methods. Which CORS configuration below is correct?

A

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

B

{
  "CORSRules": [
    {
      "AllowedOrigins": ["*"],
      "AllowedMethods": ["GET", "PUT", "DELETE"],
      "AllowedHeaders": ["*"],
      "MaxAgeSeconds": 3000
    }
  ]
}

C

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

D

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

💡 Hint

Only include the methods you want to allow.

Option C correctly lists only GET, PUT, and DELETE methods for the specified origin.

❓ security

advanced

Security risk in overly permissive CORS

An AWS S3 bucket has this CORS configuration:

{
  "CORSRules": [
    {
      "AllowedOrigins": ["*"],
      "AllowedMethods": ["GET", "PUT", "POST", "DELETE"],
      "AllowedHeaders": ["*"],
      "ExposeHeaders": ["ETag"],
      "MaxAgeSeconds": 3000
    }
  ]
}

What is the main security risk of this configuration?

A Only websites from the same domain can access the bucket.

B Any website can read and modify the bucket contents via cross-origin requests.

C The bucket will reject all cross-origin requests due to wildcard origin.

D The bucket will only allow GET requests from any origin.

💡 Hint

Think about what allowing all origins and methods means.

Allowing all origins and all methods means any website can read and write data, which is a security risk.

❓ Architecture

advanced

Designing CORS for a multi-region web app

You have a web app hosted in two regions: https://us.example.com and https://eu.example.com. Both need to access the same AWS S3 bucket. How should you configure CORS to allow both origins?

A

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

B

{
  "CORSRules": [
    {
      "AllowedOrigins": ["*"],
      "AllowedMethods": ["GET"],
      "AllowedHeaders": ["*"],
      "MaxAgeSeconds": 3000
    }
  ]
}

C

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

D

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

💡 Hint

You can list multiple origins in the AllowedOrigins array of a single CORS rule.

Option A correctly lists both origins in the AllowedOrigins array of a single CORS rule, which is supported in AWS S3.

✅ Best Practice

expert

Optimizing CORS configuration for performance and security

You want to optimize your AWS S3 bucket's CORS configuration to reduce preflight requests and improve security. Which configuration change best achieves this?

A Set AllowedOrigins to specific trusted domains, AllowedMethods to only needed methods, and increase MaxAgeSeconds.

B Set AllowedOrigins to '*', AllowedMethods to all methods, and MaxAgeSeconds to 0.

C Remove AllowedHeaders to allow any headers and set MaxAgeSeconds to 60.

D Set AllowedOrigins to specific domains and AllowedMethods to only GET, but set MaxAgeSeconds to 0.

💡 Hint

Think about reducing preflight frequency and limiting access.

Specifying trusted origins and needed methods limits exposure. Increasing MaxAgeSeconds reduces preflight requests, improving performance.

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