Why AI tools produce this: AI coding tools generate this anti-pattern by default, it appears in a large share of AI-written auth code.
Why this matters
It is passed directly to jsonwebtoken's EncodingKey::from_secret / DecodingKey::from_secret. Anyone who can read the source or git history can forge or tamper with tokens, which is a complete authentication bypass.
Load the secret at runtime from the environment or a secret manager instead, e.g. let key = std::env::var("JWT_SECRET")?; followed by EncodingKey::from_secret(key.as_bytes()). Never commit signing keys to source control.
use jsonwebtoken::EncodingKey;// ok: auth.rust.jwt.hardcoded-secret -- key comes from a variable, not a literalfn signing_key_from_var(secret: &str) -> EncodingKey { EncodingKey::from_secret(secret.as_bytes())}// ok: auth.rust.jwt.hardcoded-secret -- key loaded from the environment at runtimefn signing_key_from_env() -> EncodingKey { let secret = std::env::var("JWT_SECRET").unwrap(); EncodingKey::from_secret(secret.as_bytes())}// ok: auth.rust.jwt.hardcoded-secret -- inline env read, still not a literalfn signing_key_inline_env() -> EncodingKey { EncodingKey::from_secret(std::env::var("JWT_SECRET").unwrap().as_bytes())}
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.