oauthlint-rules 0.1.0 → 0.2.0

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/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/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

package/rules/py/flow/csrf-exempt.yml

@@ -0,0 +1,39 @@
+rules:
+  - id: auth.py.flow.csrf-exempt
+    languages:
+      - python
+    severity: WARNING
+    message: |
+      A Django view disables CSRF protection. The `@csrf_exempt` decorator
+      (from `django.views.decorators.csrf`), or `@method_decorator(csrf_exempt,
+      ...)` on a class-based view, turns off Django's CSRF middleware check for
+      that endpoint. An attacker can then forge cross-site requests that the
+      victim's browser submits with their session cookie — a CSRF vulnerability.
+
+      Do not exempt views from CSRF. Keep the default protection and submit the
+      CSRF token from your client. For machine-to-machine endpoints such as
+      webhooks, validate a signed request signature (e.g. an HMAC header)
+      instead of disabling CSRF wholesale.
+    # Scoped to the `@csrf_exempt` decorator and `@method_decorator(csrf_exempt, ...)`.
+    # A bare `import csrf_exempt` or an unrelated decorator is not matched.
+    pattern-either:
+      - patterns:
+          - pattern: |
+              @csrf_exempt
+              def $VIEW(...): ...
+      - patterns:
+          - pattern: |
+              @method_decorator(csrf_exempt, ...)
+              class $VIEW(...): ...
+    metadata:
+      oauthlint-rule-id: AUTH-PY-FLOW-005
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-flow-csrf-exempt
+      category: security
+      cwe: CWE-352
+      owasp: A01:2021
+      llm-prevalence: HIGH
+      technology:
+        - django
+      references:
+        - https://docs.djangoproject.com/en/stable/ref/csrf/
+        - https://cwe.mitre.org/data/definitions/352.html

package/rules/py/flow/debug-enabled.yml

@@ -0,0 +1,37 @@
+rules:
+  - id: auth.py.flow.debug-enabled
+    languages:
+      - python
+    severity: WARNING
+    message: |
+      Debug mode is hard-coded to `True`. In production this leaks the
+      `SECRET_KEY`, environment variables, and full tracebacks, and Flask's
+      Werkzeug debugger additionally exposes an interactive console that
+      allows remote code execution.
+
+      Never enable debug mode in production. Drive it from an environment
+      variable that defaults to off, e.g.
+      `debug=os.environ.get("FLASK_DEBUG") == "1"` (Flask) or
+      `DEBUG = os.environ.get("DJANGO_DEBUG") == "1"` (Django).
+    # Matches only the literal `True`. `debug=False`, `DEBUG = False`,
+    # `DEBUG = os.environ.get(...)`, and `config(...)` are NOT matched.
+    # `$APP` is a metavariable for any application object name.
+    pattern-either:
+      - pattern: $APP.run(..., debug=True, ...)
+      - pattern: $APP.config["DEBUG"] = True
+      - pattern: $APP.debug = True
+      - pattern: DEBUG = True
+    metadata:
+      oauthlint-rule-id: AUTH-PY-FLOW-003
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-flow-debug-enabled
+      category: security
+      cwe: CWE-489
+      owasp: A05:2021
+      llm-prevalence: HIGH
+      technology:
+        - flask
+        - django
+      references:
+        - https://flask.palletsprojects.com/en/stable/config/#DEBUG
+        - https://docs.djangoproject.com/en/stable/ref/settings/#debug
+        - https://cwe.mitre.org/data/definitions/489.html