CORS configuration in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a Rails app has this CORS config?

Given this CORS configuration in a Rails app, what will be the behavior when a browser from https://example.com tries to make a GET request?

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

A The GET request from https://example.com will succeed with CORS headers allowing it.

B The GET request will succeed but without CORS headers, causing browser to block response.

C The GET request will be blocked because only POST methods are allowed.

D The GET request will be blocked because origins must be '*' to allow any domain.

💡 Hint

Check which HTTP methods are allowed and which origins are permitted.

The config allows origins from 'https://example.com' and permits GET and POST methods. So a GET request from that origin will succeed with proper CORS headers.

📝 Syntax

intermediate

Identify the syntax error in this CORS config snippet

Which option contains the correct syntax for allowing all origins and all methods in Rails CORS config?

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

A

origins '*'
resource '*', headers: :any, methods: [get, post, put, delete]

B

origins '*'
resource '*', headers: :any, methods: [:get :post :put :delete]

C

origins '*'
resource '*', headers: :any, methods: [:get, :post, :put, :delete]

D

origins *
resource '*', headers: any, methods: [:get, :post, :put, :delete]

💡 Hint

Look carefully for missing commas or colons in the methods array.

Option C is the only one with correct syntax: origins is a string, resource has headers as symbol :any, and methods is an array of symbols with commas separating them.

🔧 Debug

advanced

Why does this Rails CORS config block requests from https://myapp.com?

A developer wrote this CORS config but requests from https://myapp.com are blocked by the browser:

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

What is the most likely reason?

A The origins string must be an array, not a string.

B The resource path '/api/*' does not match the actual request path '/api/v1/users'.

C The methods array is missing the :options method needed for preflight.

D The middleware is inserted after other middlewares, so it is ignored.

💡 Hint

Check how resource path patterns match request URLs.

The resource path '/api/*' matches only one level after /api/, but '/api/v1/users' has two levels. The pattern should be '/api/**'.

❓ state_output

advanced

What CORS headers are sent with this config for a POST request?

Given this Rails CORS config:

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

What CORS headers will the server send in response to a POST request from https://client.com?

A No CORS headers are sent because only GET is allowed.

B Access-Control-Allow-Origin: *<br>Access-Control-Allow-Methods: GET, POST<br>Access-Control-Allow-Headers: Content-Type

C Access-Control-Allow-Origin: https://client.com<br>Access-Control-Allow-Methods: GET, POST<br>Access-Control-Allow-Headers: *

D Access-Control-Allow-Origin: https://client.com<br>Access-Control-Allow-Methods: POST<br>Access-Control-Allow-Headers: *

💡 Hint

Look at origins, methods, and headers options in the config.

The config allows origin https://client.com, method POST only, and headers :any which means all headers allowed. So the server sends Access-Control-Allow-Origin with the origin, allows POST method, and allows any headers.

🧠 Conceptual

expert

Why is CORS middleware inserted before other middlewares in Rails?

In Rails, why do we insert the Rack::Cors middleware at position 0 like this?

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

Choose the best explanation.

A To ensure CORS headers are added before other middlewares process the request, especially before authentication or session middlewares.

B Because Rack::Cors must be the last middleware to modify the response after all processing.

C To delay CORS checks until after the controller has handled the request.

D It does not matter where Rack::Cors is inserted; position 0 is just a convention.

💡 Hint

Think about when CORS headers must be added in the request lifecycle.

CORS headers must be added early so browsers receive them before any authentication or session middleware might block the request. Inserting Rack::Cors at position 0 ensures it runs first.

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