Fix guide · critical · exposed_rails_database_yml

Rails config/database.yml exposed

What this rule means

Your Rails config/database.yml is publicly reachable. It contains the DB hostname, username, and (in most configs) the password in plaintext.

Why it matters

Rails apps configure database connections via config/database.yml. Three blocks: development:, test:, production: — each with adapter, host, database, username, password fields.

If the production block has a hardcoded password (rather than ENV['DATABASE_URL'] or Rails.application.credentials), and the file is reachable at /config/database.yml, the attacker has the database credentials and the hostname in one fetch.

How it ends up reachable: misconfigured asset pipeline serving config/*, Nginx with overly-permissive / location, an admin tool's "view config" endpoint left in production, or a deploy bug that put config/ inside public/.

How to fix it

  1. Pull DB credentials out of database.yml. Use DATABASE_URL env var, or Rails.application.credentials.dig(:db, :password) — both keep secrets out of source-controlled YAML.
  2. Block /config/* at the web server. config/ should never be reachable.
  3. Rotate the leaked DB credentials immediately. Generate a new password, update the production config, restart the app.
  4. Audit your deploy script. Ensure only public/ is exposed; config/, db/, lib/, storage/ should all be inaccessible.

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.

Run another inspection

Related fix guides