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.