Add Rails encrypted credentials support for OAuth providers - #859
Add Rails encrypted credentials support for OAuth providers#859anupamme wants to merge 2 commits into
Conversation
Automated security fix generated by OrbisAI Security
|
This works as intended, so that different instances can set their own credentials without changing git managed secrets files. |
|
Thanks for the detailed review. I agree that my original framing of this as a CWE-918/critical SSRF issue was too strong. The OAuth credentials here are server-side configuration values, and this initializer does not dereference them or make an HTTP request. My original test also didn't actually demonstrate an SSRF mitigation, so I don't think it is appropriate to claim that this PR fixes SSRF. I'd like to salvage the PR by narrowing its scope to credentials management:
I've updated the PR title and description accordingly, and added If there is a separate user-controlled input path that led to the original SSRF finding, I'm happy to investigate that separately rather than conflating it with this initializer change. |
Tests that Rails encrypted credentials take precedence over ENV variables, and that ENV fallback works when credentials are not configured, for all three OAuth providers (GitHub, Google, OSM). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Summary
Allow OAuth credentials to be provided through Rails encrypted credentials while preserving the existing environment-variable fallback.
Changes
The OAuth initializer now checks Rails encrypted credentials first and falls back to the corresponding environment variable when credentials are not configured there.
This supports deployments that want to keep OAuth secrets in Rails credentials while remaining backwards-compatible with existing deployments using environment variables.
Testing
Added regression coverage for:
Security note
The original version of this PR described this change as a CWE-918/SSRF remediation. After reviewing the data flow, that characterization was incorrect: these values are server-side configuration and are not user-controlled URLs or otherwise dereferenced by this initializer.
This PR therefore does not claim to fix an SSRF vulnerability. Any separate SSRF finding should be investigated at the actual user-controlled input/request path.