Fix guide · critical · exposed_rails_secrets_yml

Rails config/secrets.yml exposed

Why it matters

Rails session cookies are signed (not encrypted in modern Rails, but always signed) using secret_key_base. The signing scheme prevents tampering — if the cookie value is changed, the signature no longer matches and Rails rejects the session.

If an attacker has the secret_key_base, they can sign their own forged cookies. Forge a cookie with user_id: 1 → become user #1. Forge role: admin → become admin.

Worse: in Rails 5 and earlier (still found in many production apps), secret_key_base was also used to derive the encryption key for encrypted credentials. Leak the key → decrypt every encrypted secret in your codebase.

This is the canonical "one file leaks → game over" Rails finding.

How to fix it

1. Rotate secret_key_base immediately. Generate a new one: bin/rails secret. Update production config to use the new value. Every existing session is now invalidated — all users must re-log-in, which is the correct outcome.
2. Verify cookie signing uses the new key. Restart all app servers. If you have a multi-region deploy, restart all regions before users hit the old-key servers.
3. Move secrets out of secrets.yml. Use Rails.application.credentials (Rails 5.2+) which encrypts the credentials file at rest, or ENV['SECRET_KEY_BASE'] for direct env-var injection.
4. Block /config/* at the web server (same as /fix/exposed_rails_database_yml).
5. Audit your access logs for the period the file was exposed — anyone who fetched it had your secret_key_base.

Did vibecheck flag this on your app?

If you reached this page from a vibecheck inspection report, the redacted match in your scan output is the exact string we found in your bundle. After applying the fix above, run the inspection again — the finding should clear.