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
Anyone can forge such a token by setting alg: none and omitting the signature, so the server has no way to verify who issued it: a complete authentication bypass (CWE-347). In golang-jwt this happens when signing with jwt.SigningMethodNone or passing the jwt.UnsafeAllowNoneSignatureType sentinel to SignedString.
Never use the none algorithm. Sign tokens with a real algorithm such as HS256 (jwt.SigningMethodHS256), RS256 (jwt.SigningMethodRS256), or ES256 (jwt.SigningMethodES256) and verify them with the matching key.
VULNERABLE
vulnerable.go
package mainimport ( "github.com/golang-jwt/jwt/v5")// Case 1: signing a token with the `none` method via NewWithClaims.func signNone() *jwt.Token { // ruleid: auth.go.jwt.none-algorithm return jwt.NewWithClaims(jwt.SigningMethodNone, jwt.MapClaims{ "sub": "1234567890", })}// Case 2: passing the UnsafeAllowNoneSignatureType sentinel to SignedString.func signWithUnsafeSentinel(token *jwt.Token) (string, error) { // ruleid: auth.go.jwt.none-algorithm return token.SignedString(jwt.UnsafeAllowNoneSignatureType)}// Case 3: building a token with the none method via jwt.New.func newNone() *jwt.Token { // ruleid: auth.go.jwt.none-algorithm return jwt.New(jwt.SigningMethodNone)}
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.