Proposal to update wiki documentation on Rails CSRF protection

The wiki page about mitigating CVE-2025-9284 is out of date. We should update the recommendation to be the one @jkowens originally came up with (source).

Currently, the wiki suggests Rails developers use the omniauth-rails_csrf_protection gem to mitigate the vulnerability. However, that gem's README now states:

OmniAuth has provided a built-in solution to mitigate against CVE-2015-9284 since version 2.0.0. You should be able to mitigate against this vulnerability by adding this configuration to your application:

复制

OmniAuth.config.request_validation_phase = OmniAuth::AuthenticityTokenProtection.new(key: :_csrf_token)

This gem will continued to be maintained as an alternative to the solution above.

This is confusing for Rails developers trying to set up OmniAuth, as it is not clear whether the gem is the best solution or not. This open PR in the OmniAuth repo reflects these changes in the project README, but I think updating this wiki page is also important.

I didn't want to make the edit without allowing for discussion of some kind, so I created this issue. If every thing looks good, I will update the wiki page sometime this week.

The proposed new wiki page is below:

These instructions are up-to-date as of February 21, 2025, and OmniAuth version v2.1.4. They are written to address CVE-2015-9284, and are consolidated from these discussions (here, here, and here) and account for the changes introduced in OmniAuth v2.0.0.

The Issue

This vulnerability is mitigated by disallowing GET requests during OmniAuth's request_phase and including a CSRF token with requests. OmniAuth by default accomplishes the first mitigation criteria. Although OmniAuth provides most of the functionality needed to mitigate the vulnerability, special action must be taken to ensure CSRF tokens are included and handled properly. This depends on the implementation of your app.

Using GET requests

A key part of resolving this vulnerability is refusing GET requests to /auth/:provider endpoints.

As of OmniAuth v2.0.0, GET requests are disabled by default, so no further action is required. If you are using an earlier version of omniauth, you must configure your application to only accept get requests:

OmniAuth.config.allowed_request_methods = [:post]
# And to prevent OmniAuth from logging a warning with each GET:
OmniAuth.config.silence_get_warning = true

If the use of GET requests to /auth/:provider is essential for your application (for example, if you are ever redirecting to /auth/:provider as part of an authentication process), then you will need to put together a more involved solution for your specific needs. This may mean redirecting to a standard log-in screen which includes link_to 'Log in', '/auth/:provider', method: :post or another POST/form-based approach (like button_to).

Mitigating in Rails applications

Rails has built-in handling for CSRF tokens, but this is not compatible with OmniAuth as is because Rails' security tokens use a custom key.

The recommendation is to configure OmniAuth to use Rails' CSRF token key. Previously the omniauth-rails_csrf_protection gem was recommended to accomplish this, but that is no longer necessary. Simply adding the following config and only using POST requests is sufficient:

1. Include the following configuration in your application:

# config/omniauth.rb or similar
OmniAuth.config.request_validation_phase = OmniAuth::AuthenticityTokenProtection.new(key: :_csrf_token)

1. Update all links to /auth/:provider to use POST requests. For example:

link_to 'Sign in via X', '/auth/:provider', method: :post
# or
button_to 'Sign in via X', '/auth/:provider'

Because GET is disabled by default, not doing this will cause the passthru to third-parties to fail, giving this Devise error message: "Not found. Authentication passthru."

1. If you are continuing to use GET requests to access /auth/:provider then you will need to explicitly enable it. Do so by including the configuration from the Using GET Requests section in your app. (But remember that using GET requests for /auth/:provider is not recommended and you should try to stick to POST requests if at all possible)

Mitigating in non-Rails applications

By default, OmniAuth uses rack-protection's AuthenticityToken class to validate authenticity tokens.

If you are using a rack based framework like sinatra, you can find an example of how to add authenticity tokens to your view here.

Your main responsibility is to include CSRF tokens in your forms:

1. Ensure your Rack application has rack-protection configured and sessions enabled.

2. Update all links to /auth/:provider to use POST requests with a CSRF token. You'll need forms that POST to /auth/:provider with a hidden field containing the session's CSRF token. See the official Sinatra example and this gist for reference.

3. If you need GET access to /auth/:provider (not recommended), do so by including the configuration from the Using GET Requests section in your app.

OmniAuth.config.allowed_request_methods = [:post, :get]
# And to prevent OmniAuth from logging a warning with each GET:
OmniAuth.config.silence_get_warning = true

Regression Testing

Should you wish to add regression testing to validate that this vulnerability is mitigated then you can consult the following examples:

• RSpec Example
• Minitest Example - OmniAuth 1.9.x
• Minitest Example - OmniAuth 2.x