A Rails secret_key_base / secret_key is assigned a hard-coded string literal.

Why this matters

This value keys the whole application's signed/encrypted cookies (including the session cookie) and message verifiers: committed to source control it is one search away from letting an attacker forge session cookies and impersonate any user (CWE-798). Inlining a literal secret to make an app "just run" is a classic LLM-generated mistake.

Never assign the secret in code. Store it in Rails.application.credentials (encrypted) or read it from the environment, e.g. ENV.fetch("SECRET_KEY_BASE"), and rotate the leaked value out of source control and git history.

# frozen_string_literal: true

# ruleid: auth.ruby.secret.hardcoded-secret-key-base
Rails.application.config.secret_key_base = "3f9a8c1e0b7d4a2f6c5e8d1b9a0f7c3e"

# ruleid: auth.ruby.secret.hardcoded-secret-key-base
MyApp::Application.config.secret_key = "s3cr3t-development-key"

# frozen_string_literal: true

# Read from the environment, not a literal.
Rails.application.config.secret_key_base = ENV["SECRET_KEY_BASE"]

Rails.application.config.secret_key_base = ENV.fetch("SECRET_KEY_BASE")

# Encrypted Rails credentials.
Rails.application.config.secret_key_base = Rails.application.credentials.secret_key_base

Suppressing this rule

If a finding is a genuine false positive, scope the suppression to the exact line and leave a reason, never disable the rule project-wide. Disable directives are line-scoped by design.

// oauthlint-disable-next-line auth.ruby.secret.hardcoded-secret-key-base -- <reason>

References