CORS configuration in Ruby on Rails - Step-by-Step Execution

Concept Flow - CORS configuration

Client sends request

↓

Server receives request

↓

Check Origin header

↓

Is Origin allowed?

No→Reject request or no CORS headers

Yes↓

Add CORS headers to response

↓

Send response back to client

The server checks the request's origin and adds CORS headers if allowed, enabling cross-origin access.

Execution Sample

Ruby on Rails

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'https://example.com'
    resource '*', headers: :any, methods: [:get, :post]
  end
end

This code configures Rails to allow CORS requests from https://example.com for GET and POST methods.

Execution Table

Step	Action	Request Origin	Allowed Origins	CORS Headers Added	Response Sent
1	Client sends request	https://example.com	https://example.com	No	No
2	Server receives request	https://example.com	https://example.com	No	No
3	Check if origin is allowed	https://example.com	https://example.com	No	No
4	Add CORS headers to response	https://example.com	https://example.com	Yes	No
5	Send response back to client	https://example.com	https://example.com	Yes	Yes
6	Client sends request	https://notallowed.com	https://example.com	No	No
7	Server receives request	https://notallowed.com	https://example.com	No	No
8	Check if origin is allowed	https://notallowed.com	https://example.com	No	No
9	Send response back to client	https://notallowed.com	https://example.com	No	Yes

💡 Requests from allowed origins get CORS headers; others do not but still get a response.

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	After Step 8	After Step 9
request_origin	N/A	https://example.com	https://example.com	https://example.com	https://notallowed.com	https://notallowed.com
allowed_origins	['https://example.com']	['https://example.com']	['https://example.com']	['https://example.com']	['https://example.com']	['https://example.com']
cors_headers_added	false	false	true	true	false	false
response_sent	false	false	false	true	false	true

Key Moments - 2 Insights

Why does the server add CORS headers only for some origins?

The server checks if the request's origin matches the allowed origins list (see execution_table step 3). Only if it matches, CORS headers are added (step 4). This prevents unauthorized cross-origin access.

What happens if the origin is not allowed?

The server does not add CORS headers but still sends a response (see execution_table steps 8 and 9). The browser will block access to the response due to missing CORS headers.

Visual Quiz - 3 Questions

Look at the execution table, at which step are CORS headers first added for an allowed origin?

A Step 3

B Step 4

C Step 5

D Step 2

💡 Hint

Check the 'CORS Headers Added' column for the first 'Yes' value for https://example.com.

According to the variable tracker, what is the value of 'cors_headers_added' after step 8 for a disallowed origin?

A false

B true

C undefined

D null

💡 Hint

Look at the 'cors_headers_added' row under 'After Step 8' column.

If we add 'https://notallowed.com' to allowed origins, how would the execution table change at step 8?

A Response would not be sent at step 9

B Request origin would change to https://example.com

C CORS headers would be added at step 8

D No change in CORS headers

💡 Hint

Adding origin to allowed list means CORS headers get added when that origin requests (see step 3 logic).

Concept Snapshot

CORS configuration in Rails:
- Use Rack::Cors middleware in config/application.rb
- Specify allowed origins with origins 'https://example.com'
- Define allowed resources and HTTP methods
- Server checks Origin header and adds CORS headers if allowed
- Browsers enforce CORS based on these headers

Full Transcript

CORS configuration in Rails works by adding middleware that checks the origin of incoming requests. If the origin matches the allowed list, the server adds special headers to the response. These headers tell the browser it is safe to share the response with the requesting site. If the origin is not allowed, the server sends the response without these headers, so the browser blocks access. The example code uses Rack::Cors middleware to allow requests from https://example.com for GET and POST methods. The execution table shows how requests from allowed and disallowed origins are handled step-by-step, including when headers are added and responses sent. The variable tracker follows key variables like request origin and whether CORS headers were added. Key moments clarify why headers are only added for allowed origins and what happens otherwise. The quiz tests understanding of when headers are added and how changing allowed origins affects behavior.

Practice

1. What is the main purpose of configuring CORS in a Rails application?

easy

A. To speed up database queries

B. To control which external websites can access your app's resources

C. To manage user sessions securely

D. To style the frontend pages

Solution

1. Step 1: Understand CORS role

   CORS (Cross-Origin Resource Sharing) controls access from other websites to your app's resources.

2. Step 2: Identify main purpose

   It restricts or allows external origins to make requests, enhancing security.

3. Final Answer:

   To control which external websites can access your app's resources -> Option B

4. Quick Check:

   CORS controls access = B [OK]

Hint: Remember CORS is about cross-site access control [OK]

Common Mistakes:

• Confusing CORS with database or session management
• Thinking CORS affects frontend styling
• Assuming CORS speeds up app performance

2. Which of the following is the correct way to add CORS middleware in a Rails app initializer?

easy

A. Rails.application.config.middleware.insert_before 0, Rack::Cors do
allow do
origins '*'
resource '*', headers: :any, methods: [:get, :post]
end
end

B. Rails.middleware.use Rack::Cors do
allow do
origins '*'
resource '*', headers: :any, methods: [:get, :post]
end
end

C. config.middleware.add Rack::Cors do
allow do
origins '*'
resource '*', headers: :any, methods: [:get, :post]
end
end

D. Rails.application.middleware.insert_after 0, Rack::Cors do
allow do
origins '*'
resource '*', headers: :any, methods: [:get, :post]
end
end

Solution

1. Step 1: Recall correct middleware insertion

   In Rails, middleware is added using Rails.application.config.middleware.insert_before or insert_after.

2. Step 2: Identify correct syntax

   The common pattern is insert_before 0, Rack::Cors with a block for configuration.

3. Final Answer:

   Rails.application.config.middleware.insert_before 0, Rack::Cors do allow do origins '*' resource '*', headers: :any, methods: [:get, :post] end end -> Option A

4. Quick Check:

   Use insert_before 0 with config.middleware = C [OK]

Hint: Use Rails.application.config.middleware.insert_before 0 for CORS [OK]

Common Mistakes:

• Using Rails.middleware instead of Rails.application.config.middleware
• Using insert_after instead of insert_before 0
• Missing config in middleware insertion

3. Given this CORS config in Rails initializer:

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'https://example.com'
    resource '*', headers: :any, methods: [:get, :post]
  end
end

What happens if a request comes from 'https://evil.com'?

medium

A. The request is blocked due to origin mismatch

B. The request causes a server error

C. The request is allowed but only GET method works

D. The request is allowed with all headers and methods

Solution

1. Step 1: Analyze allowed origins

   The config allows only 'https://example.com' origin.

2. Step 2: Check request origin

   Request from 'https://evil.com' is not in allowed origins, so it is blocked by CORS policy.

3. Final Answer:

   The request is blocked due to origin mismatch -> Option A

4. Quick Check:

   Origin not allowed = request blocked = D [OK]

Hint: Only origins listed in config are allowed [OK]

Common Mistakes:

• Assuming wildcard '*' allows all origins when specific origins set
• Thinking request causes server error instead of CORS block
• Confusing allowed methods with allowed origins

4. You wrote this CORS config:

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'
    resource '*', headers: :any, methods: [:get, :post, :put]
  end
end

But PUT requests from frontend are failing with CORS errors. What is the likely problem?

medium

A. The methods list is missing :put

B. The frontend is not sending the correct Origin header

C. The server needs to allow OPTIONS method for preflight

D. The origins '*' is too restrictive

Solution

1. Step 1: Check methods allowed

   PUT is included in methods, so it's not missing.

2. Step 2: Understand CORS preflight

   PUT requests trigger a preflight OPTIONS request which must be allowed by server.

3. Step 3: Identify missing OPTIONS method

   OPTIONS method is not listed, so preflight fails causing CORS error.

4. Final Answer:

   The server needs to allow OPTIONS method for preflight -> Option C

5. Quick Check:

   Preflight OPTIONS missing = CORS fail = A [OK]

Hint: Always allow OPTIONS method for CORS preflight [OK]

Common Mistakes:

• Forgetting to allow OPTIONS method
• Assuming '*' origin is restrictive
• Blaming frontend Origin header without checking server

5. You want to allow CORS only for two trusted domains: 'https://app1.com' and 'https://app2.com'. Which config correctly implements this securely in Rails?

hard

A. Rails.application.config.middleware.insert_before 0, Rack::Cors do
allow do
origins 'app1.com'
resource '*', headers: :any, methods: [:get, :post, :options]
end
allow do
origins 'app2.com'
resource '*', headers: :any, methods: [:get, :post, :options]
end
end

B. Rails.application.config.middleware.insert_before 0, Rack::Cors do
allow do
origins '*'
resource '*', headers: :any, methods: :any
end
end

C. Rails.application.config.middleware.insert_before 0, Rack::Cors do
allow do
origins 'app1.com', 'app2.com'
resource '*', headers: :any, methods: [:get, :post]
end
end

D. Rails.application.config.middleware.insert_before 0, Rack::Cors do
allow do
origins 'https://app1.com', 'https://app2.com'
resource '*', headers: :any, methods: [:get, :post, :options]
end
end

Solution

1. Step 1: Identify correct origins format

   Origins must include full URLs with protocol for security, so 'https://app1.com' and 'https://app2.com' are correct.

2. Step 2: Check methods and resource

   Allowing common methods including OPTIONS for preflight is necessary.

3. Step 3: Compare options

   Rails.application.config.middleware.insert_before 0, Rack::Cors do allow do origins 'https://app1.com', 'https://app2.com' resource '*', headers: :any, methods: [:get, :post, :options] end end correctly lists both origins in one allow block with proper methods and full URLs.

4. Final Answer:

   Rails.application.config.middleware.insert_before 0, Rack::Cors do allow do origins 'https://app1.com', 'https://app2.com' resource '*', headers: :any, methods: [:get, :post, :options] end end -> Option D

5. Quick Check:

   Trusted full origins with methods including OPTIONS = A [OK]

Hint: List full trusted origins with needed methods including OPTIONS [OK]

Common Mistakes:

• Using '*' origin which is insecure
• Omitting protocol in origins
• Not allowing OPTIONS method for preflight
• Splitting origins into multiple allow blocks unnecessarily