CORS configuration in AWS - Step-by-Step Execution

Process Flow - CORS configuration

Client sends request

↓

Browser checks CORS policy

↓

Browser sends OPTIONS preflight request?

No→Send actual request

Yes↓

Server responds with CORS headers

↓

Browser checks headers

↓

Allow or block request based on CORS

↓

Client receives response or error

This flow shows how a browser and server interact to enforce CORS rules, allowing or blocking cross-origin requests.

Execution Sample

AWS

PUT /bucket-name
{
  "CORSConfiguration": {
    "CORSRules": [{
      "AllowedOrigins": ["https://example.com"],
      "AllowedMethods": ["GET", "POST"]
    }]
  }
}

This code sets a CORS policy on an AWS S3 bucket allowing GET and POST from https://example.com.

Process Table

Step	Action	Request Type	CORS Headers Sent	Browser Decision	Result
1	Client sends GET request from https://example.com	GET	Origin: https://example.com	Check if origin allowed	Proceed to send request
2	Browser sends OPTIONS preflight for POST	OPTIONS	Origin: https://example.com, Access-Control-Request-Method: POST	Wait for server response	Waiting
3	Server responds with CORS headers	OPTIONS Response	Access-Control-Allow-Origin: https://example.com, Access-Control-Allow-Methods: GET, POST	Check if POST allowed	Allowed
4	Browser sends actual POST request	POST	Origin: https://example.com	Check if origin allowed	Proceed to send request
5	Server responds to POST	POST Response	Access-Control-Allow-Origin: https://example.com	Allow response	Response received
6	Client sends GET request from https://malicious.com	GET	Origin: https://malicious.com	Check if origin allowed	Blocked
7	Browser blocks response	N/A	N/A	Origin not allowed	Error: CORS policy blocks request

💡 Execution stops when browser blocks request from disallowed origin or completes allowed request.

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	After Step 7
Origin	N/A	https://example.com	https://example.com	https://example.com	https://malicious.com
AllowedOrigins	["https://example.com"]	["https://example.com"]	["https://example.com"]	["https://example.com"]	["https://example.com"]
Request Allowed	false	true	true	true	false
Response Received	false	false	false	true	false

Key Moments - 2 Insights

Why does the browser send an OPTIONS preflight request before the actual POST?

The browser sends OPTIONS to check if the server allows the POST method from the origin. This is shown in execution_table step 2 and 3 where the preflight is sent and the server responds with allowed methods.

Why is the request from https://malicious.com blocked?

Because the CORS policy only allows https://example.com. The browser checks the origin against AllowedOrigins and blocks it as shown in execution_table step 6 and 7.

Visual Quiz - 3 Questions

Look at the execution table, what CORS header does the server send in response to the OPTIONS preflight?

A Access-Control-Allow-Methods: GET, POST

B Access-Control-Allow-Origin: https://example.com

C Access-Control-Allow-Headers: Content-Type

D Access-Control-Allow-Credentials: true

💡 Hint

Check step 3 in the execution_table under 'CORS Headers Sent'

At which step does the browser block the request due to CORS policy?

A Step 6

B Step 7

C Step 5

D Step 4

💡 Hint

Look for 'Blocked' or 'Error' in the 'Result' column of execution_table

If AllowedOrigins included "https://malicious.com", how would the 'Request Allowed' variable change at step 7?

A It would remain false

B It would become undefined

C It would become true

D It would cause an error

💡 Hint

Check variable_tracker for 'Request Allowed' at step 7

Concept Snapshot

CORS configuration controls which origins can access resources.
Browsers enforce CORS by sending preflight OPTIONS requests for some methods.
Server responds with headers like Access-Control-Allow-Origin and Access-Control-Allow-Methods.
If origin or method not allowed, browser blocks the request.
Set CORS on AWS S3 via CORSConfiguration with AllowedOrigins and AllowedMethods.

Full Transcript

CORS configuration is a security feature that controls which websites can access resources on a server. When a client from a different origin tries to access a resource, the browser checks the CORS policy. For some requests, it sends a preflight OPTIONS request to ask the server if the actual request is allowed. The server responds with headers indicating allowed origins and methods. If the origin or method is not allowed, the browser blocks the request. In AWS S3, you configure CORS by setting AllowedOrigins and AllowedMethods in the bucket's CORSConfiguration. This example showed a client from https://example.com allowed to GET and POST, while a client from https://malicious.com was blocked.

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