oauthlint-rules 0.1.1 → 0.2.1

package/rules/java/crypto/weak-password-hash.yml

@@ -0,0 +1,47 @@
+rules:
+  - id: auth.java.crypto.weak-password-hash
+    languages:
+      - java
+    severity: ERROR
+    message: |
+      A password is being hashed with a fast, general-purpose digest from the
+      JCA `MessageDigest` (MD5, SHA-1, SHA-256, SHA-512). These algorithms are
+      designed to be fast, which makes offline brute-force and rainbow-table
+      attacks cheap — they are NOT suitable for storing passwords (CWE-916).
+
+      Use a dedicated, slow password-hashing function with a per-password salt
+      and a tunable work factor: BCrypt (`BCryptPasswordEncoder`), Argon2
+      (`Argon2PasswordEncoder`), or PBKDF2 (`Pbkdf2PasswordEncoder` /
+      `SecretKeyFactory` with `PBKDF2WithHmacSHA256`). These resist brute-force
+      by design.
+    # Anchored to the *password* character of the input: the digested/updated
+    # argument must be named like a password (metavariable-regex on $PW), and a
+    # weak MessageDigest must be instantiated in the same enclosing method
+    # (pattern-inside). This avoids flagging `MessageDigest.getInstance("SHA-256")`
+    # used for file checksums or non-password fingerprints, and does not touch
+    # real password hashers (BCrypt/Argon2/PBKDF2).
+    patterns:
+      - pattern-either:
+          - pattern: $MD.digest($PW.getBytes(...))
+          - pattern: $MD.digest($PW)
+          - pattern: $MD.update($PW.getBytes(...))
+          - pattern: $MD.update($PW)
+      - metavariable-regex:
+          metavariable: $PW
+          regex: (?i).*(password|passwd|pwd).*
+      - pattern-inside: |
+          MessageDigest $MD = MessageDigest.getInstance("=~/(?i)^(MD5|SHA-?1|SHA-?256|SHA-?512)$/");
+          ...
+    metadata:
+      oauthlint-rule-id: AUTH-JAVA-CRYPTO-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/java-crypto-weak-password-hash
+      category: security
+      cwe: CWE-916
+      owasp: A02:2021
+      llm-prevalence: HIGH
+      technology:
+        - java.security
+      references:
+        - https://cwe.mitre.org/data/definitions/916.html
+        - https://docs.spring.io/spring-security/reference/features/authentication/password-storage.html
+        - https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

package/rules/java/jwt/hardcoded-secret.yml

@@ -0,0 +1,43 @@
+rules:
+  - id: auth.java.jwt.hardcoded-secret
+    languages:
+      - java
+    severity: ERROR
+    message: |
+      A JWT signing key is hard-coded as a string literal (CWE-798). Anyone with
+      access to the source, the compiled artifact, or the version-control history
+      can read the secret and forge valid tokens — changing the subject, roles,
+      or expiry at will, because the signature will still verify. This is a common
+      AI-generated mistake: a placeholder secret is pasted inline to "make signing
+      work" and is never moved out of the code.
+
+      Load the signing key from outside the source: an environment variable
+      (`System.getenv("JWT_SECRET")`), a configuration property, or a dedicated
+      secret manager (Vault, AWS Secrets Manager, etc.). With jjwt, build the key
+      from those bytes via `Keys.hmacShaKeyFor(secret.getBytes(...))`. Never commit
+      the key, and rotate any secret that has already been checked in.
+    # jjwt (io.jsonwebtoken): flag only STRING LITERALS in a signing-key position.
+    #   - Keys.hmacShaKeyFor("literal".getBytes(...))   (current API)
+    #   - signWith(SignatureAlgorithm.HS*, "literal")    (legacy API)
+    #   - setSigningKey("literal" [.getBytes(...)])       (parser side)
+    # A variable, System.getenv(...), or a loaded Key/SecretKey is NOT matched
+    # because the argument is constrained to a `"..."` literal.
+    pattern-either:
+      - pattern: io.jsonwebtoken.security.Keys.hmacShaKeyFor("...".getBytes(...))
+      - pattern: Keys.hmacShaKeyFor("...".getBytes(...))
+      - pattern: $B.signWith($ALG, "...")
+      - pattern: $P.setSigningKey("...")
+      - pattern: $P.setSigningKey("...".getBytes(...))
+    metadata:
+      oauthlint-rule-id: AUTH-JAVA-JWT-002
+      oauthlint-doc-url: https://oauthlint.dev/rules/java-jwt-hardcoded-secret
+      category: security
+      cwe: CWE-798
+      owasp: API2:2023
+      llm-prevalence: HIGH
+      technology:
+        - jjwt
+      references:
+        - https://github.com/jwtk/jjwt#signing-key
+        - https://cwe.mitre.org/data/definitions/798.html
+        - https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

package/rules/java/jwt/unsigned-jwt.yml

@@ -0,0 +1,41 @@
+rules:
+  - id: auth.java.jwt.unsigned-jwt
+    languages:
+      - java
+    severity: ERROR
+    message: |
+      This JWT is created or parsed without a signature, so its contents are
+      neither authenticated nor tamper-proof (CWE-347). An unsecured ("alg=none")
+      token can be forged by anyone — changing the claims (e.g. the subject or
+      roles) costs nothing because there is no signature to verify. This is a
+      common AI-generated mistake: the "plaintext"/"unsecured" JWT API is reached
+      for during prototyping and never swapped for a signed token.
+
+      Sign tokens and verify their signatures. With nimbus-jose-jwt use
+      `SignedJWT` (and verify with a `JWSVerifier`); with jjwt build tokens via
+      `Jwts.builder()...signWith(key)` and parse them with `parseSignedClaims`
+      (or the legacy `parseClaimsJws`) instead of `parseClaimsJwt` /
+      `parsePlaintextJwt`.
+    # nimbus-jose-jwt: PlainJWT is the unsecured (alg=none) variant.
+    # jjwt (io.jsonwebtoken): parseClaimsJwt / parsePlaintextJwt parse an
+    # UNSIGNED JWT; the signed counterparts are parseSignedClaims /
+    # parseClaimsJws and are intentionally not matched.
+    pattern-either:
+      - pattern: new com.nimbusds.jwt.PlainJWT(...)
+      - pattern: new PlainJWT(...)
+      - pattern: $P.parseClaimsJwt(...)
+      - pattern: $P.parsePlaintextJwt(...)
+    metadata:
+      oauthlint-rule-id: AUTH-JAVA-JWT-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/java-jwt-unsigned-jwt
+      category: security
+      cwe: CWE-347
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - jjwt
+        - nimbus-jose-jwt
+      references:
+        - https://connect2id.com/products/nimbus-jose-jwt/examples/unsecured-jwt
+        - https://github.com/jwtk/jjwt#reading-a-jwt
+        - https://cwe.mitre.org/data/definitions/347.html

package/rules/java/session/fixation-disabled.yml

@@ -0,0 +1,34 @@
+rules:
+  - id: auth.java.session.fixation-disabled
+    languages:
+      - java
+    severity: ERROR
+    message: |
+      Spring Security session fixation protection is disabled via
+      `sessionFixation().none()`. With `none()`, the session ID is NOT
+      regenerated when a user authenticates, so an attacker who fixes the
+      victim's session ID before login (e.g. by planting a cookie) keeps a
+      valid session and hijacks the authenticated account (CWE-384).
+
+      Leave the default (`changeSessionId`) in place, or use `migrateSession()`
+      to copy the existing session attributes into a new session ID. Never use
+      `none()`.
+    # Covers the legacy fluent form
+    # `sessionManagement().sessionFixation().none()` and the Spring Security 6
+    # lambda DSL `sessionManagement(s -> s.sessionFixation(f -> f.none()))`.
+    # Targets only `none()` — never `changeSessionId()` or `migrateSession()`.
+    pattern-either:
+      - pattern: $S.sessionFixation().none()
+      - pattern: $S.sessionFixation($F -> $F.none())
+    metadata:
+      oauthlint-rule-id: AUTH-JAVA-SESSION-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/java-session-fixation-disabled
+      category: security
+      cwe: CWE-384
+      owasp: A07:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - spring-security
+      references:
+        - https://docs.spring.io/spring-security/reference/servlet/authentication/session-management.html
+        - https://cwe.mitre.org/data/definitions/384.html

package/rules/java/tls/trust-all-certs.yml

@@ -0,0 +1,48 @@
+rules:
+  - id: auth.java.tls.trust-all-certs
+    languages:
+      - java
+    severity: ERROR
+    message: |
+      TLS hostname verification is disabled. A permissive `HostnameVerifier`
+      that returns `true` for every host — or Apache HttpClient's
+      `NoopHostnameVerifier` — accepts any certificate regardless of the name
+      it was issued for, so a man-in-the-middle can present a certificate for a
+      different domain and the connection succeeds (CWE-295). This is a common
+      AI-generated mistake — the verifier is stubbed out to "fix" a handshake
+      or certificate error during development and shipped to production.
+
+      Never accept all hosts. Leave the default hostname verification in place
+      (do not call `setHostnameVerifier`/`setDefaultHostnameVerifier` with a
+      permissive verifier), or fix the trust chain by supplying a proper
+      truststore so the certificate validates normally.
+    # Targets only the permissive verifier: a lambda returning a constant true,
+    # an anonymous HostnameVerifier whose verify(...) returns true, and Apache
+    # HttpClient's NoopHostnameVerifier. A HostnameVerifier with real
+    # (non-trivial) logic and the default verifier are not matched.
+    pattern-either:
+      # Lambda that always returns true: (hostname, session) -> true
+      - pattern: ($HOST, $SESSION) -> true
+      # Anonymous HostnameVerifier whose verify(...) just returns true.
+      - pattern: |
+          new HostnameVerifier() {
+            public boolean verify(String $H, SSLSession $S) { return true; }
+          }
+      # Apache HttpClient NoopHostnameVerifier (constructor or INSTANCE).
+      - pattern: new org.apache.http.conn.ssl.NoopHostnameVerifier()
+      - pattern: new NoopHostnameVerifier()
+      - pattern: org.apache.http.conn.ssl.NoopHostnameVerifier.INSTANCE
+      - pattern: NoopHostnameVerifier.INSTANCE
+    metadata:
+      oauthlint-rule-id: AUTH-JAVA-TLS-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/java-tls-trust-all-certs
+      category: security
+      cwe: CWE-295
+      owasp: A02:2021
+      llm-prevalence: HIGH
+      technology:
+        - javax.net.ssl
+        - apache-httpclient
+      references:
+        - https://cwe.mitre.org/data/definitions/295.html
+        - https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/HostnameVerifier.html

package/rules/java/web/csrf-disabled.yml

@@ -0,0 +1,35 @@
+rules:
+  - id: auth.java.web.csrf-disabled
+    languages:
+      - java
+    severity: ERROR
+    message: |
+      Spring Security CSRF protection is disabled. With CSRF off, an attacker
+      can forge state-changing requests that a logged-in victim's browser
+      submits with their session cookie (CWE-352). This is one of the most
+      common AI-generated Spring mistakes — `csrf().disable()` is pasted in to
+      "make the API work" and never removed.
+
+      Keep CSRF protection enabled. For a stateless API authenticated with
+      bearer tokens (not cookies), scope it instead — e.g. ignore specific
+      paths or use a `CookieCsrfTokenRepository` — rather than disabling it
+      globally.
+    # Covers the legacy fluent form `http.csrf().disable()`, the Spring
+    # Security 6 lambda DSL `http.csrf(c -> c.disable())`, and the method
+    # reference `http.csrf(AbstractHttpConfigurer::disable)`.
+    pattern-either:
+      - pattern: $H.csrf().disable()
+      - pattern: $H.csrf($C -> $C.disable())
+      - pattern: $H.csrf(AbstractHttpConfigurer::disable)
+    metadata:
+      oauthlint-rule-id: AUTH-JAVA-WEB-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/java-web-csrf-disabled
+      category: security
+      cwe: CWE-352
+      owasp: A01:2021
+      llm-prevalence: HIGH
+      technology:
+        - spring-security
+      references:
+        - https://docs.spring.io/spring-security/reference/servlet/exploits/csrf.html
+        - https://cwe.mitre.org/data/definitions/352.html

package/rules/java/web/frame-options-disabled.yml

@@ -0,0 +1,37 @@
+rules:
+  - id: auth.java.web.frame-options-disabled
+    languages:
+      - java
+    severity: WARNING
+    message: |
+      Spring Security's `X-Frame-Options` header is disabled. This header is
+      the browser's clickjacking defense — with it off, an attacker can embed
+      the application in a hidden `<iframe>` on a malicious page and trick a
+      logged-in victim into clicking UI elements they cannot see (CWE-1021).
+
+      Keep `X-Frame-Options` set to DENY or SAMEORIGIN — e.g.
+      `frameOptions(f -> f.sameOrigin())` or `frameOptions(f -> f.deny())`. If
+      you need to allow framing from a specific set of origins, use a Content
+      Security Policy `frame-ancestors` directive instead of disabling the
+      protection outright.
+    # Covers the legacy fluent form `http.headers().frameOptions().disable()`,
+    # the Spring Security 6 lambda DSL
+    # `http.headers(h -> h.frameOptions(f -> f.disable()))`, and the method
+    # reference `frameOptions(FrameOptionsConfig::disable)`. Only the `disable`
+    # terminal is flagged; `sameOrigin()` and `deny()` are left alone.
+    pattern-either:
+      - pattern: $H.frameOptions().disable()
+      - pattern: $H.frameOptions($F -> $F.disable())
+      - pattern: $H.frameOptions(FrameOptionsConfig::disable)
+    metadata:
+      oauthlint-rule-id: AUTH-JAVA-WEB-003
+      oauthlint-doc-url: https://oauthlint.dev/rules/java-web-frame-options-disabled
+      category: security
+      cwe: CWE-1021
+      owasp: A05:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - spring-security
+      references:
+        - https://docs.spring.io/spring-security/reference/servlet/exploits/headers.html
+        - https://cwe.mitre.org/data/definitions/1021.html

package/rules/java/web/permit-all.yml

@@ -0,0 +1,36 @@
+rules:
+  - id: auth.java.web.permit-all
+    languages:
+      - java
+    severity: ERROR
+    message: |
+      Spring Security authorizes every request without authentication via
+      `anyRequest().permitAll()`. Because `anyRequest()` is the catch-all
+      matcher, this makes the entire application publicly accessible — any
+      endpoint, including state-changing and sensitive ones, can be reached
+      without a logged-in user (CWE-862, broken access control). This is a
+      common AI-generated Spring mistake: the default-allow line is pasted in
+      to "make it work" and the intended access rules are never added.
+
+      Require authentication by default with `anyRequest().authenticated()`,
+      and open only the specific public routes explicitly, e.g.
+      `requestMatchers("/public/**").permitAll()`. Granting `permitAll()` on a
+      specific matcher is fine; granting it on `anyRequest()` is not.
+    # Targets the catch-all `anyRequest().permitAll()` in both the legacy
+    # fluent chain and the Spring Security 6 lambda DSL. `$X` lets the chain be
+    # rooted on `http`, `auth`, an `authorizeHttpRequests(...)` registry, or
+    # any earlier matcher in the chain.
+    pattern-either:
+      - pattern: $X.anyRequest().permitAll()
+    metadata:
+      oauthlint-rule-id: AUTH-JAVA-WEB-002
+      oauthlint-doc-url: https://oauthlint.dev/rules/java-web-permit-all
+      category: security
+      cwe: CWE-862
+      owasp: A01:2021
+      llm-prevalence: HIGH
+      technology:
+        - spring-security
+      references:
+        - https://docs.spring.io/spring-security/reference/servlet/authorization/authorize-http-requests.html
+        - https://cwe.mitre.org/data/definitions/862.html

package/rules/jwt/decode-without-verify.yml

@@ -0,0 +1,56 @@
+rules:
+  - id: auth.jwt.decode-without-verify
+    languages:
+      - javascript
+      - typescript
+    severity: WARNING
+    message: |
+      `jwt.decode()` from `jsonwebtoken` only parses the token — it does NOT
+      verify the signature. Trusting any claim returned by `decode()` (e.g.
+      `sub`, `role`, `scope`) lets an attacker forge a token and bypass
+      authentication entirely.
+
+      Use `jwt.verify(token, secret, { algorithms: ['RS256'] })`, which checks
+      the signature before returning the payload. Only use `decode()` for
+      non-security-sensitive inspection (e.g. reading `kid` before verifying).
+    # Scoped to the `jsonwebtoken` library via the common alias `jwt`, mirroring
+    # no-expiration.yml / alg-none.yml. `jwt.verify(...)` is never matched, and
+    # other libraries (`jose.decodeJwt`, a bare `decodeJwt(...)`) are out of
+    # scope. We also support the destructured import `import { decode } from
+    # 'jsonwebtoken'`, scoped to that import so an unrelated `decode()` is safe.
+    #
+    # FP guard: jsonwebtoken's `decode(token[, options])` takes the token STRING
+    # as its first argument and is synchronous. Other libraries that expose a
+    # `jwt.decode` — notably next-auth's own jose-backed helper — are called as
+    # `await jwt.decode({ token, salt, ... })` (awaited, single options object).
+    # We exclude both shapes so we don't flag those (real-world FP on next-auth).
+    pattern-either:
+      - patterns:
+          - pattern-either:
+              - pattern: 'jwt.decode($X)'
+              - pattern: 'jwt.decode($X, $OPTS)'
+          - pattern-not: 'jwt.decode({...})'
+          - pattern-not: 'jwt.decode({...}, $OPTS)'
+          - pattern-not: 'await jwt.decode(...)'
+      - patterns:
+          - pattern-inside: |
+              import { ..., decode, ... } from 'jsonwebtoken'
+              ...
+          - pattern-either:
+              - pattern: 'decode($X)'
+              - pattern: 'decode($X, $OPTS)'
+          - pattern-not: 'decode({...})'
+          - pattern-not: 'decode({...}, $OPTS)'
+          - pattern-not: 'await decode(...)'
+    metadata:
+      oauthlint-rule-id: AUTH-JWT-009
+      oauthlint-doc-url: https://oauthlint.dev/rules/jwt-decode-without-verify
+      category: security
+      cwe: CWE-347
+      owasp: API2:2023
+      llm-prevalence: HIGH
+      technology:
+        - jsonwebtoken
+      references:
+        - https://github.com/auth0/node-jsonwebtoken#jwtdecodetoken--options
+        - https://cwe.mitre.org/data/definitions/347.html

package/rules/jwt/localstorage.yml

@@ -21,10 +21,22 @@ rules:
     # NOT match the bare words `auth`/`access`/`refresh`/`session` because they
     # appear as substrings of innocuous keys (author_filter, auto_refresh,
     # access_count, sidebar_session) and produced false positives.
+    # A write to web storage (`setItem(k, v)` or `store[k] = v`) is flagged when
+    # EITHER the key is a token-named string literal OR the value is a token-named
+    # identifier. The latter catches `localStorage.setItem(TOKEN_KEY, token)`,
+    # where the key is a variable — the most common real-world shape. We match
+    # only the strong words `token`/`jwt`/`bearer`/`credential`/`api_key` (never
+    # bare `auth`/`access`/`refresh`/`session`, which appear in innocuous keys
+    # like `author_filter`, `auto_refresh`, `access_count`).
     pattern-either:
+      # `setItem(key, value)` where a strong token word appears in EITHER the key
+      # or the value. Matching the whole call as one range (rather than separate
+      # key/value patterns) catches `setItem(TOKEN_KEY, token)` — the common shape
+      # where the key is a variable — without double-counting literal-key lines.
       - patterns:
           - pattern-regex: |-
-              (?:window\.|globalThis\.|self\.)?(?:localStorage|sessionStorage)\.setItem\(\s*['"][^'"]*(?i:token|jwt|bearer|credential|api[_-]?key)[^'"]*['"]
+              (?:window\.|globalThis\.|self\.)?(?:localStorage|sessionStorage)\.setItem\([^)]*?(?i:token|jwt|bearer|credential|api[_-]?key)
+      # Bracket assignment with a token-named string-literal key.
       - patterns:
           - pattern-regex: |-
               (?:window\.|globalThis\.|self\.)?(?:localStorage|sessionStorage)\[\s*['"][^'"]*(?i:token|jwt|bearer|credential|api[_-]?key)[^'"]*['"]\s*\]\s*=

package/rules/jwt/no-algorithms-allowlist.yml

@@ -0,0 +1,38 @@
+rules:
+  - id: auth.jwt.no-algorithms-allowlist
+    languages:
+      - javascript
+      - typescript
+    severity: WARNING
+    message: |
+      `jwt.verify(...)` is called without an explicit `algorithms` allowlist.
+      Without pinning the accepted algorithms, a token signed with an
+      unexpected algorithm — or even `alg: none` on older versions — can be
+      accepted, opening the door to algorithm-confusion attacks.
+
+      Always pass the algorithm(s) you actually expect, e.g.
+      `{ algorithms: ['RS256'] }`.
+    # Scoped to the `jsonwebtoken` library by matching the common alias
+    # `jwt`. Only `jwt.verify(...)` is flagged — `jwt.sign(...)`,
+    # `jwt.decode(...)` and `jose.jwtVerify(...)` are intentionally ignored.
+    pattern-either:
+      - pattern: 'jwt.verify($T, $SECRET)'
+      - patterns:
+          - pattern: 'jwt.verify($T, $SECRET, $OPTS)'
+          - metavariable-pattern:
+              metavariable: $OPTS
+              patterns:
+                - pattern-not: '{..., algorithms: ..., ...}'
+                - pattern: '{...}'
+    metadata:
+      oauthlint-rule-id: AUTH-JWT-010
+      oauthlint-doc-url: https://oauthlint.dev/rules/jwt-no-algorithms-allowlist
+      category: security
+      cwe: CWE-347
+      owasp: API2:2023
+      llm-prevalence: HIGH
+      technology:
+        - jsonwebtoken
+      references:
+        - https://datatracker.ietf.org/doc/html/rfc7518#section-3.1
+        - https://owasp.org/www-project-api-security/

package/rules/oauth/no-nonce.yml

@@ -0,0 +1,55 @@
+rules:
+  - id: auth.oauth.no-nonce
+    languages:
+      - javascript
+      - typescript
+    severity: WARNING
+    message: |
+      OIDC authorization request (scope contains `openid`) is being built
+      WITHOUT a `nonce` parameter. The nonce binds the id_token to this
+      specific authorization request — without it, an attacker can replay or
+      substitute a stolen/forged id_token (OIDC Core §3.1.2.1).
+
+      Generate a cryptographically random `nonce`, store it in the
+      session/cookie, send it on the authorize call, and verify the `nonce`
+      claim in the returned id_token. It is REQUIRED for the implicit and
+      hybrid flows and RECOMMENDED for the authorization-code flow.
+    pattern-either:
+      # Inline authorize URL carrying an OIDC scope (scope=openid…) but no
+      # nonce. The endpoint path is not hardcoded (Google /o/oauth2/v2/auth,
+      # Auth0/Okta /authorize, …). Only OIDC requests carry `openid` in scope.
+      - patterns:
+          - pattern-regex: |-
+              ['"]https?://[^'"\s]+\?[^'"]*scope=[^'"&]*openid[^'"]*['"]
+          - pattern-regex: |-
+              response_type=
+          # Suppress when the SAME URL string already carries a nonce. A bare
+          # `nonce=` not-regex would be tested against the narrow
+          # `response_type=` span and never subtract, so match the whole URL.
+          - pattern-not-regex: |-
+              ['"]https?://[^'"\s]+\?[^'"]*nonce=[^'"]*['"]
+      # Programmatic URLSearchParams build (AST object match — robust to key
+      # order and object length). Fires when response_type is present and the
+      # scope value contains `openid`, but nonce is not (covers both
+      # `nonce: x` and the `nonce` shorthand). The scope test is an AST
+      # metavariable-regex so it composes with the `nonce` pattern-not on the
+      # same node (a free-floating pattern-regex would not).
+      - patterns:
+          - pattern: 'new URLSearchParams({..., response_type: $R, ...})'
+          - pattern: 'new URLSearchParams({..., scope: $S, ...})'
+          - metavariable-regex:
+              metavariable: $S
+              regex: .*openid.*
+          - pattern-not: 'new URLSearchParams({..., nonce: $N, ...})'
+          - pattern-not: 'new URLSearchParams({..., nonce, ...})'
+    metadata:
+      oauthlint-rule-id: AUTH-OAUTH-010
+      oauthlint-doc-url: https://oauthlint.dev/rules/oauth-no-nonce
+      category: security
+      cwe: CWE-294
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - oidc
+      references:
+        - https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

package/rules/oauth/no-state-validation.yml

@@ -13,24 +13,46 @@ rules:
       Compare the received `state` to the value you stored before
       redirecting (session, signed cookie, or Redis). Reject the callback
       if it's missing or doesn't match.
-    # Suppress when the received `state` is referenced inside ANY `if`
-    # condition — that's the validation. The deep-expression operator
-    # `<... state ...>` makes this order-agnostic and helper-aware, so
-    # `if (req.query.state !== stored)`, `if (stored === req.query.state)`, and
-    # `if (!verifyState(req.query.state))` are all treated as safe (the previous
-    # exact-shape patterns only matched one operand order → false positives).
+    # Suppress when the received `state` is validated. Two shapes count as
+    # validation:
+    #   1. The read appears directly inside an `if` condition, e.g.
+    #      `if (req.query.state !== stored)`. The deep-expression operator
+    #      `<... state ...>` makes this order-agnostic and helper-aware, so
+    #      `if (stored === req.query.state)` and `if (!verifyState(req.query.state))`
+    #      are all safe (the previous exact-shape patterns only matched one
+    #      operand order → false positives).
+    #   2. The read is captured into a variable that is later compared, e.g.
+    #      `const state = url.searchParams.get("state"); ...; if (state !== stored)`.
+    #      This is the most common real-world shape (the callback reads state
+    #      once, then validates the local) and the inline-`if` suppressors alone
+    #      miss it. The sequence patterns below match the read assigned to `$S`
+    #      followed (after any statements) by an `if` that references `$S`.
     pattern-either:
       - patterns:
           - pattern-either:
               - pattern: '$REQ.query.state'
               - pattern: '$REQ.body.state'
               - pattern: '$URL.searchParams.get("state")'
+          # (1) read used directly inside an `if` condition
           - pattern-not-inside: |
               if (<... $REQ.query.state ...>) { ... }
           - pattern-not-inside: |
               if (<... $REQ.body.state ...>) { ... }
           - pattern-not-inside: |
               if (<... $URL.searchParams.get("state") ...>) { ... }
+          # (2) read captured into a local that is later validated in an `if`
+          - pattern-not-inside: |
+              $S = $REQ.query.state;
+              ...
+              if (<... $S ...>) { ... }
+          - pattern-not-inside: |
+              $S = $REQ.body.state;
+              ...
+              if (<... $S ...>) { ... }
+          - pattern-not-inside: |
+              $S = $URL.searchParams.get("state");
+              ...
+              if (<... $S ...>) { ... }
     metadata:
       oauthlint-rule-id: AUTH-OAUTH-007
       oauthlint-doc-url: https://oauthlint.dev/rules/oauth-no-state-validation

package/rules/oauth/pkce-plain.yml

@@ -0,0 +1,40 @@
+rules:
+  - id: auth.oauth.pkce-plain
+    languages:
+      - javascript
+      - typescript
+    severity: WARNING
+    message: |
+      PKCE is configured with `code_challenge_method=plain`. The `plain`
+      method sends the `code_verifier` itself as the `code_challenge`, so an
+      attacker who intercepts the authorization request learns the verifier
+      and PKCE provides no protection against authorization-code interception.
+
+      Use `code_challenge_method=S256`: derive `code_challenge =
+      BASE64URL-NoPad(SHA256(code_verifier))` (RFC 7636 §4.2). S256 is
+      mandatory for clients that can compute SHA-256.
+    pattern-either:
+      # Query-string form: inline authorize URL, template fragment, or any
+      # string carrying the plain method. Matched literally so S256 never hits.
+      - pattern-regex: |-
+          code_challenge_method=plain\b
+      # Object literal: { code_challenge_method: 'plain' } (AST match — robust
+      # to key order and object length).
+      - pattern: "{..., code_challenge_method: 'plain', ...}"
+      - pattern: '{..., code_challenge_method: "plain", ...}'
+      # URLSearchParams.set / .append with the plain method.
+      - pattern: $P.set('code_challenge_method', 'plain')
+      - pattern: $P.set("code_challenge_method", "plain")
+      - pattern: $P.append('code_challenge_method', 'plain')
+      - pattern: $P.append("code_challenge_method", "plain")
+    metadata:
+      oauthlint-rule-id: AUTH-OAUTH-011
+      oauthlint-doc-url: https://oauthlint.dev/rules/oauth-pkce-plain
+      category: security
+      cwe: CWE-757
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - oauth
+      references:
+        - https://datatracker.ietf.org/doc/html/rfc7636#section-4.2

package/rules/py/cookie/insecure-flags.yml

@@ -0,0 +1,41 @@
+rules:
+  - id: auth.py.cookie.insecure-flags
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      A session/auth cookie is issued with a security attribute explicitly
+      disabled. `secure=False` lets the cookie travel over plain HTTP (it can be
+      sniffed on the wire), and `httponly=False` exposes it to JavaScript so an
+      XSS payload can read and exfiltrate it — either way the session token is
+      at risk of theft (CWE-614, OWASP A05:2021). The same applies to Django's
+      `SESSION_COOKIE_SECURE = False`, `CSRF_COOKIE_SECURE = False`, and
+      `SESSION_COOKIE_HTTPONLY = False` settings.
+
+      Always set Secure + HttpOnly (and ideally `SameSite`) on auth cookies,
+      e.g. `response.set_cookie("session", token, secure=True, httponly=True,
+      samesite="Lax")` or, in Django settings, `SESSION_COOKIE_SECURE = True`
+      and `SESSION_COOKIE_HTTPONLY = True`.
+    # Matches ONLY the literal `False` on these specific kwargs/settings keys.
+    # `secure=True`, `SESSION_COOKIE_SECURE = True`, and the absence of the
+    # kwarg are NOT flagged. `$RESP` matches any response variable name.
+    pattern-either:
+      - pattern: $RESP.set_cookie(..., secure=False, ...)
+      - pattern: $RESP.set_cookie(..., httponly=False, ...)
+      - pattern: SESSION_COOKIE_SECURE = False
+      - pattern: CSRF_COOKIE_SECURE = False
+      - pattern: SESSION_COOKIE_HTTPONLY = False
+    metadata:
+      oauthlint-rule-id: AUTH-PY-COOKIE-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-cookie-insecure-flags
+      category: security
+      cwe: CWE-614
+      owasp: A05:2021
+      llm-prevalence: HIGH
+      technology:
+        - flask
+        - django
+      references:
+        - https://docs.djangoproject.com/en/stable/ref/settings/#session-cookie-secure
+        - https://flask.palletsprojects.com/en/stable/api/#flask.Response.set_cookie
+        - https://cwe.mitre.org/data/definitions/614.html