oauthlint-rules 0.2.5 → 0.3.0

package/rules/py/flow/oauth-credential-in-log.yml

@@ -0,0 +1,91 @@
+rules:
+  - id: auth.py.flow.oauth-credential-in-log
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      An OAuth/OIDC credential taken from the request — an authorization
+      `code`, an `access_token` / `refresh_token` / `id_token`, a bearer
+      `token`, a `client_secret`, or the raw `Authorization` header — flows
+      into a logging call (`print`, `logging.*`, or a `logger.*`). Logs are
+      written to files, shipped to aggregators (Datadog, Splunk, CloudWatch)
+      and read by people and systems that should never see live credentials. A
+      leaked authorization code or token can be replayed to impersonate the
+      user or complete the OAuth exchange (CWE-532).
+
+      Never log the raw credential. Redact or mask it before logging, log a
+      non-sensitive identifier instead (a user id, a key id), or drop the field
+      entirely.
+    # Taint mode so indirection is caught — `at = request.args.get("access_token");
+    # logger.info(at)` flags, not just the inline form. The source list is
+    # narrowed to OAuth/OIDC credential field names (and the Authorization
+    # header) via a metavariable-regex on the accessor key, so logging a benign
+    # field such as `request.args.get("page")` does not fire. Routing the value
+    # through a redaction/masking helper clears the taint.
+    mode: taint
+    pattern-sources:
+      # Credential-named request fields: request.args.get("code"),
+      # request.form["access_token"], flask.request.json.get("id_token"), …
+      - patterns:
+          - pattern-either:
+              - pattern: request.args.get($K)
+              - pattern: request.form.get($K)
+              - pattern: request.values.get($K)
+              - pattern: request.json.get($K)
+              - pattern: request.args[$K]
+              - pattern: request.form[$K]
+              - pattern: request.values[$K]
+              - pattern: request.json[$K]
+              - pattern: flask.request.args.get($K)
+              - pattern: flask.request.form.get($K)
+              - pattern: flask.request.json.get($K)
+          - metavariable-regex:
+              metavariable: $K
+              regex: (?i)^["'](?:code|access[_-]?token|accesstoken|refresh[_-]?token|refreshtoken|id[_-]?token|idtoken|token|client[_-]?secret|clientsecret)["']$
+      # Raw Authorization header.
+      - patterns:
+          - pattern-either:
+              - pattern: request.headers.get($K)
+              - pattern: request.headers[$K]
+              - pattern: flask.request.headers.get($K)
+          - metavariable-regex:
+              metavariable: $K
+              regex: (?i)^["']authorization["']$
+    pattern-sanitizers:
+      # Redaction / masking helpers — the value that reaches the log is no
+      # longer the live credential.
+      - pattern: redact(...)
+      - pattern: mask(...)
+      - pattern: mask_token(...)
+    pattern-sinks:
+      - patterns:
+          - pattern-either:
+              - pattern: print(...)
+              - pattern: logging.info(...)
+              - pattern: logging.debug(...)
+              - pattern: logging.warning(...)
+              - pattern: logging.error(...)
+              - pattern: logging.exception(...)
+              - pattern: logging.critical(...)
+              # logger.<level>(...) — a log-named receiver with a log-level method.
+              - patterns:
+                  - pattern: $LOG.$LEVEL(...)
+                  - metavariable-regex:
+                      metavariable: $LOG
+                      regex: (?i)^.*log(?:ger)?$
+                  - metavariable-regex:
+                      metavariable: $LEVEL
+                      regex: ^(?:info|debug|warning|warn|error|exception|critical)$
+    metadata:
+      oauthlint-rule-id: AUTH-PY-FLOW-009
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-flow-oauth-credential-in-log
+      category: security
+      cwe: CWE-532
+      owasp: API8:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - flask
+      references:
+        - https://cwe.mitre.org/data/definitions/532.html
+        - https://datatracker.ietf.org/doc/html/rfc6749#section-10.3
+        - https://owasp.org/API-Security/editions/2023/en/0xa8-security-misconfiguration/

package/rules/py/flow/secret-in-response.yml

@@ -0,0 +1,88 @@
+rules:
+  - id: auth.py.flow.secret-in-response
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      A server-side secret read from the environment flows into an HTTP
+      response sent back to the client — leaking it (CWE-200). Anything you
+      return from a Flask view (via `jsonify(...)`, `make_response(...)`,
+      `Response(...)`) is visible to every caller, so an env value whose name
+      looks like a credential (`API_KEY`, `CLIENT_SECRET`, `*_TOKEN`,
+      `*_PASSWORD`, a private key, an access key, ...) must never reach it.
+
+      Never send a server secret to the client. Return only the data the
+      caller needs; keep credentials server-side. If a value genuinely must be
+      surfaced, redact or mask it first (`redact(...)` / `mask_secret(...)`),
+      and prefer exposing only public configuration (names prefixed
+      `PUBLIC_` / `NEXT_PUBLIC_` / `VITE_`) to clients.
+    # REVERSE-direction taint: the SOURCE is the secret (an os.environ / getenv
+    # value whose name looks like a credential), the SINK is the HTTP response.
+    # Taint mode so indirection (secret = os.getenv('CLIENT_SECRET');
+    # return jsonify(secret=secret)) is caught, not just the inline form.
+    # `metavariable-regex` constrains the env var NAME to credential-looking
+    # words while excluding public-by-convention prefixes, and passing the value
+    # through a redaction/mask helper clears the taint. The sink focuses the
+    # response value argument. `by-side-effect` is unsupported on semgrep 1.157,
+    # so the source is constrained inline rather than via a propagator.
+    mode: taint
+    pattern-sources:
+      - patterns:
+          - pattern-either:
+              - pattern: os.environ[$KEY]
+              - pattern: os.environ.get($KEY)
+              - pattern: 'os.environ.get($KEY, ...)'
+              - pattern: os.getenv($KEY)
+              - pattern: 'os.getenv($KEY, ...)'
+              # Qualified `from os import environ, getenv` forms.
+              - pattern: environ[$KEY]
+              - pattern: environ.get($KEY)
+              - pattern: 'environ.get($KEY, ...)'
+              - pattern: getenv($KEY)
+              - pattern: 'getenv($KEY, ...)'
+          # $KEY must look like a credential AND must not be a public-by-
+          # convention name. A single regex: a negative lookahead drops the
+          # PUBLIC_/NEXT_PUBLIC_/VITE_ prefixes (so NEXT_PUBLIC_API_KEY is NOT a
+          # source), then a credential keyword must appear. The optional leading
+          # quote tolerates semgrep binding the string literal with or without
+          # its quotes; `(?i)` makes the whole match case-insensitive.
+          - metavariable-regex:
+              metavariable: $KEY
+              regex: '(?i)^[''"]?(?!(?:NEXT_PUBLIC_|VITE_|PUBLIC_))\w*(?:secret|password|passwd|token|api[_-]?key|private[_-]?key|client[_-]?secret|credential|access[_-]?key)'
+    pattern-sanitizers:
+      # Redaction / masking helpers: a secret passed through one of these is no
+      # longer sensitive, so returning the result is safe.
+      - pattern: redact(...)
+      - pattern: mask(...)
+      - pattern: mask_secret(...)
+    pattern-sinks:
+      - patterns:
+          - pattern-either:
+              # Flask response constructors — the reliable sinks. Each covers a
+              # positional value and a keyword value (jsonify(secret=...)), and
+              # taint reaching a value nested inside (e.g. a dict) still fires.
+              - pattern: 'jsonify(..., $X, ...)'
+              - pattern: 'jsonify(..., $K=$X, ...)'
+              - pattern: 'flask.jsonify(..., $X, ...)'
+              - pattern: 'flask.jsonify(..., $K=$X, ...)'
+              - pattern: 'make_response(..., $X, ...)'
+              - pattern: 'make_response(..., $K=$X, ...)'
+              - pattern: 'flask.make_response(..., $X, ...)'
+              - pattern: 'flask.make_response(..., $K=$X, ...)'
+              - pattern: 'Response(..., $X, ...)'
+              - pattern: 'Response(..., $K=$X, ...)'
+              - pattern: 'flask.Response(..., $X, ...)'
+              - pattern: 'flask.Response(..., $K=$X, ...)'
+          - focus-metavariable: $X
+    metadata:
+      oauthlint-rule-id: AUTH-PY-FLOW-008
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-flow-secret-in-response
+      category: security
+      cwe: CWE-200
+      owasp: API3:2023
+      llm-prevalence: HIGH
+      technology:
+        - flask
+      references:
+        - https://cwe.mitre.org/data/definitions/200.html
+        - https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/

package/rules/py/jwt/algorithm-confusion.yml

@@ -0,0 +1,48 @@
+rules:
+  - id: auth.py.jwt.algorithm-confusion
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      A JWT is decoded with an `algorithms` allowlist that mixes a symmetric
+      HMAC algorithm (HS256/HS384/HS512) with an asymmetric one (RS*/ES*/PS*).
+      This enables the "algorithm confusion" attack: an attacker who knows your
+      RSA/EC PUBLIC key can sign a forged token with HMAC, using that public key
+      string as the shared secret. Because HS* is also accepted, PyJWT verifies
+      the forgery with the public key as the HMAC secret and treats it as valid
+      — a complete authentication bypass.
+
+      Allow only ONE algorithm family — the one you actually use. If you issue
+      RS256 tokens, pin `jwt.decode(token, public_key, algorithms=["RS256"])`
+      and never also accept an HS* algorithm with the same verification key.
+
+      CWE-327: Use of a Broken or Risky Cryptographic Algorithm.
+    # Distinct from auth.py.jwt.no-algorithms (which flags a MISSING `algorithms`
+    # allowlist): here the allowlist is PRESENT but dangerously MIXES a symmetric
+    # (HS*) and an asymmetric (RS*/ES*/PS*) family in the same `jwt.decode` call.
+    #
+    # A single metavariable-regex over the bound list literal `$ALGS` requires
+    # BOTH families to appear (order-independent lookaheads), so single-family
+    # lists like ["RS256"] or ["HS256"] never match. `(?s)` lets `.` span a
+    # multi-line list. The `import jwt` guard pins this to PyJWT (joserfc and
+    # other libs expose a different `jwt.decode`).
+    patterns:
+      - pattern: jwt.decode(..., algorithms=$ALGS, ...)
+      - metavariable-regex:
+          metavariable: $ALGS
+          regex: (?s)(?=.*['"]HS(256|384|512)['"])(?=.*['"](RS|ES|PS)(256|384|512)['"])
+      - pattern-inside: |
+          import jwt
+          ...
+    metadata:
+      oauthlint-rule-id: AUTH-PY-JWT-006
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-jwt-algorithm-confusion
+      category: security
+      cwe: CWE-327
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - PyJWT
+      references:
+        - https://cwe.mitre.org/data/definitions/327.html
+        - https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

package/rules/py/jwt/untrusted-verify-key.yml

@@ -0,0 +1,75 @@
+rules:
+  - id: auth.py.jwt.untrusted-verify-key
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      Untrusted request input flows into the verification key or the
+      `algorithms` allowlist of `jwt.decode(...)` (PyJWT / python-jose). When
+      the attacker controls the key, they sign their own forged token and
+      supply the matching key, so every token "verifies" — a complete
+      authentication bypass. When the attacker controls `algorithms`, they can
+      downgrade verification (e.g. to `HS256` against a public key, or to
+      `none` on older libraries) and defeat the signature check (CWE-347,
+      Improper Verification of Cryptographic Signature).
+
+      The verification key and the accepted algorithms must be fixed
+      server-side. Pin `algorithms` to a constant allowlist
+      (`algorithms=["RS256"]`) and resolve the key from trusted configuration or
+      a vetted key set keyed by a validated `kid` — never from `request.args`,
+      `request.form`, `request.json`, or `request.headers`.
+    # Taint mode with the sink FOCUSED on the key / algorithms argument — never
+    # the token. The token is supposed to come from the request, so focusing on
+    # it would false-positive on every correct call; focusing on the key and the
+    # `algorithms` value fires only when the attacker controls verification
+    # itself. Routing a candidate algorithm/key through an allow-list /
+    # validation helper clears the taint. Distinct from
+    # auth.py.jwt.algorithm-confusion (HS* + an asymmetric family) and
+    # auth.py.jwt.no-algorithms (a MISSING allowlist): this is about a
+    # request-CONTROLLED key or algorithm.
+    mode: taint
+    pattern-sources:
+      - pattern: request.args.get(...)
+      - pattern: request.args.getlist(...)
+      - pattern: request.args[...]
+      - pattern: request.form.get(...)
+      - pattern: request.form[...]
+      - pattern: request.values.get(...)
+      - pattern: request.json.get(...)
+      - pattern: request.headers.get(...)
+      - pattern: request.headers[...]
+      - pattern: flask.request.args.get(...)
+      - pattern: flask.request.headers.get(...)
+    pattern-sanitizers:
+      # A candidate algorithm or key vetted against an allow-list / validator is
+      # no longer attacker-controlled when it reaches decode().
+      - pattern: is_allowed_algorithm(...)
+      - pattern: validate_algorithm(...)
+      - pattern: is_allowed_key(...)
+      - pattern: load_trusted_key(...)
+    pattern-sinks:
+      # Request input used as the verification key (positional and keyword forms).
+      - patterns:
+          - pattern-either:
+              - pattern: jwt.decode($T, $SINK)
+              - pattern: jwt.decode($T, $SINK, ...)
+              - pattern: jwt.decode($T, key=$SINK, ...)
+          - focus-metavariable: $SINK
+      # Request input used as the accepted `algorithms`.
+      - patterns:
+          - pattern: jwt.decode(..., algorithms=$SINK, ...)
+          - focus-metavariable: $SINK
+    metadata:
+      oauthlint-rule-id: AUTH-PY-JWT-007
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-jwt-untrusted-verify-key
+      category: security
+      cwe: CWE-347
+      owasp: API2:2023
+      llm-prevalence: LOW
+      technology:
+        - pyjwt
+        - python-jose
+      references:
+        - https://cwe.mitre.org/data/definitions/347.html
+        - https://datatracker.ietf.org/doc/html/rfc7518#section-3.1
+        - https://owasp.org/www-project-api-security/

package/rules/py/oauth/insecure-token-endpoint.yml

@@ -0,0 +1,40 @@
+rules:
+  - id: auth.py.oauth.insecure-token-endpoint
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      An OAuth/OIDC endpoint is being contacted over cleartext `http://`.
+      Authorization codes, `client_secret`, access/refresh tokens, and the
+      `code_verifier` then travel unencrypted — a network attacker can read
+      or rewrite them and take over the flow.
+
+      RFC 6749 §3.1 / §10.9 require TLS for the authorization and token
+      endpoints. Use `https://` for every authorize, token, userinfo, and
+      `.well-known` discovery URL. `http://localhost` and loopback addresses
+      are fine for local development and are not flagged.
+    # A string literal (including an f-string) that targets an OAuth/OIDC
+    # endpoint over http://. Required OAuth markers keep this precise: a generic
+    # http URL is NOT flagged, only one carrying an authorize/token request or an
+    # /oauth, /connect/token, or /.well-known path. `https://` cannot match (the
+    # scheme is the literal `http://`), and the localhost / loopback dev hosts
+    # are subtracted below.
+    patterns:
+      - pattern-regex: |-
+              ['"]http://[^'"\s]+(?:response_type=|client_id=|client_secret=|grant_type=|code_challenge=|/oauth2?/|/connect/token|/o/oauth2|/authorize|/oauth/token|/\.well-known/)[^'"]*['"]
+      - pattern-not-regex: |-
+              http://(?:localhost|127\.0\.0\.1|0\.0\.0\.0|\[::1\])
+    metadata:
+      oauthlint-rule-id: AUTH-PY-OAUTH-002
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-oauth-insecure-token-endpoint
+      category: security
+      cwe: CWE-319
+      owasp: A02:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - oauth2
+        - oidc
+      references:
+        - https://datatracker.ietf.org/doc/html/rfc6749#section-3.1
+        - https://datatracker.ietf.org/doc/html/rfc6749#section-10.9
+        - https://cwe.mitre.org/data/definitions/319.html

package/rules/py/oauth/insecure-transport-env.yml

@@ -0,0 +1,43 @@
+rules:
+  - id: auth.py.oauth.insecure-transport-env
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      `OAUTHLIB_INSECURE_TRANSPORT` is being set, which disables oauthlib's
+      HTTPS requirement for OAuth flows (`requests-oauthlib`, Authlib's
+      requests integration, Django OAuth Toolkit). oauthlib raises
+      `InsecureTransportError` to stop you exchanging codes and tokens over
+      cleartext; setting this variable silences that guard, so authorization
+      codes, `client_secret`, and access/refresh tokens travel over plain
+      `http://` where a network attacker can read or rewrite them (CWE-319).
+
+      Remove this assignment and serve every OAuth endpoint over `https://`.
+      For local development use a loopback HTTPS listener or a tunnel rather
+      than disabling transport security in code that can ship to production.
+    # Matches only an ASSIGNMENT (or setdefault/putenv) of the
+    # OAUTHLIB_INSECURE_TRANSPORT key. Merely reading it
+    # (`os.environ.get("OAUTHLIB_INSECURE_TRANSPORT")`) is not flagged, and other
+    # environment keys are untouched. Semgrep normalises quote style, so the
+    # single- and double-quoted spellings are both covered.
+    pattern-either:
+      - pattern: os.environ["OAUTHLIB_INSECURE_TRANSPORT"] = ...
+      - pattern: os.environ.setdefault("OAUTHLIB_INSECURE_TRANSPORT", ...)
+      - pattern: os.putenv("OAUTHLIB_INSECURE_TRANSPORT", ...)
+      - pattern: environ["OAUTHLIB_INSECURE_TRANSPORT"] = ...
+      - pattern: environ.setdefault("OAUTHLIB_INSECURE_TRANSPORT", ...)
+    metadata:
+      oauthlint-rule-id: AUTH-PY-OAUTH-004
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-oauth-insecure-transport-env
+      category: security
+      cwe: CWE-319
+      owasp: A02:2021
+      llm-prevalence: HIGH
+      technology:
+        - oauthlib
+        - requests-oauthlib
+        - authlib
+      references:
+        - https://requests-oauthlib.readthedocs.io/en/latest/oauth2_workflow.html
+        - https://datatracker.ietf.org/doc/html/rfc6749#section-3.1
+        - https://cwe.mitre.org/data/definitions/319.html

package/rules/py/oauth/ropc-grant.yml

@@ -0,0 +1,50 @@
+rules:
+  - id: auth.py.oauth.ropc-grant
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      OAuth token request uses the Resource Owner Password Credentials
+      grant (`grant_type=password`). The app collects the user's password
+      and replays it to the authorization server — exactly what OAuth was
+      designed to avoid. It cannot support federation, MFA, or step-up
+      auth, and any compromise of your service exposes raw user passwords.
+
+      The OAuth 2.0 Security BCP (RFC 9700 §2.4) forbids ROPC and OAuth 2.1
+      removes it entirely. Use the authorization-code flow with PKCE
+      (`grant_type=authorization_code`) for user login, or
+      `client_credentials` for machine-to-machine. In Python this covers a
+      `requests`/`httpx`/`urllib` body, an OAuth client call, or a
+      URL-encoded body string.
+    # Regex-based so it is library-agnostic across requests, httpx, urllib and
+    # OAuth clients. The `password` value is matched as an exact quoted literal
+    # (dict / kwarg form) or bounded token (URL-encoded form), so
+    # `grant_type=password_reset` and `grant_type=client_credentials` never
+    # fire, and a dynamic `grant_type=grant` variable is not a literal and is
+    # not flagged.
+    pattern-either:
+      # Dict entry `"grant_type": "password"` or keyword `grant_type="password"`.
+      # The optional quote after the key covers the dict form's closing `"`.
+      - pattern-regex: |-
+              grant_type['"]?\s*[:=]\s*['"]password['"]
+      # URL-encoded request body: "grant_type=password&username=…". The value is
+      # bounded so `grant_type=password_reset` is not flagged.
+      - pattern-regex: |-
+              [?&'"]grant_type=password(?:[&'"\s]|$)
+      # Tuple/list pair form: ("grant_type", "password").
+      - pattern-regex: |-
+              ['"]grant_type['"]\s*,\s*['"]password['"]
+    metadata:
+      oauthlint-rule-id: AUTH-PY-OAUTH-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-oauth-ropc-grant
+      category: security
+      cwe: CWE-522
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - oauth2
+        - requests
+      references:
+        - https://datatracker.ietf.org/doc/html/rfc9700#section-2.4
+        - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1#section-2.4
+        - https://cwe.mitre.org/data/definitions/522.html

package/rules/py/oauth/static-state.yml

@@ -0,0 +1,45 @@
+rules:
+  - id: auth.py.oauth.static-state
+    languages:
+      - python
+    severity: WARNING
+    message: |
+      OAuth authorization request sends a hardcoded, constant `state`
+      value. A static `state` provides ZERO CSRF protection — the whole
+      point is an unguessable, per-request value that you store and then
+      compare on the callback. A literal that ships in your source is known
+      to everyone and identical on every request, so an attacker can forge
+      a matching callback.
+
+      Generate `state` fresh per request from a CSPRNG
+      (`secrets.token_urlsafe(32)`), persist it in the session, and verify
+      it when the provider redirects back.
+    pattern-either:
+      # Authorize parameter dict carrying a `response_type` (so we know it is an
+      # authorize request, not some unrelated `state` field) AND a string-LITERAL
+      # `state`. A per-request value is a variable or a function call, which is
+      # not a quoted literal and so does not match.
+      - patterns:
+          - pattern: '{..., "response_type": ..., ...}'
+          - pattern-either:
+              - pattern: '{..., "state": "$S", ...}'
+      # Inline authorize URL string literal carrying both response_type and a
+      # constant state value. A dynamic state would be an f-string with `{state}`,
+      # whose `{` is excluded from the value character class below.
+      - patterns:
+          - pattern-regex: |-
+              ['"]https?://[^'"\s]+\?[^'"]*response_type=[^'"]*['"]
+          - pattern-regex: |-
+              ['"]https?://[^'"\s]+\?[^'"]*state=[A-Za-z0-9._~%-]+[^'"]*['"]
+    metadata:
+      oauthlint-rule-id: AUTH-PY-OAUTH-003
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-oauth-static-state
+      category: security
+      cwe: CWE-330
+      owasp: API1:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - oauth2
+      references:
+        - https://datatracker.ietf.org/doc/html/rfc6749#section-10.12
+        - https://cwe.mitre.org/data/definitions/330.html

package/rules/py/oauth/token-request-verify-disabled.yml

@@ -0,0 +1,41 @@
+rules:
+  - id: auth.py.oauth.token-request-verify-disabled
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      An OAuth client fetches or refreshes a token with TLS certificate
+      verification disabled (`verify=False`). The token request carries the
+      `client_secret`, the authorization `code`, and the issued access/refresh
+      tokens; with verification off, an attacker who can intercept the
+      connection presents any certificate and reads or tampers with them — a
+      classic man-in-the-middle on the most sensitive call in the flow
+      (CWE-295).
+
+      Never pass `verify=False` to `fetch_token` / `refresh_token` /
+      `fetch_access_token` (Authlib, requests-oauthlib). Leave verification on
+      (the default) so the system CA bundle is used, or point `verify` at a CA
+      bundle path for a private CA.
+    # Scoped to OAuth client token methods (Authlib OAuth1/2 sessions,
+    # requests-oauthlib) and the literal `verify=False`. `verify=True` and
+    # `verify="/path/ca.pem"` are not flagged. This is distinct from
+    # auth.py.flow.requests-verify-disabled, which covers the `requests` HTTP
+    # verbs (`get`/`post`/…); here the sink is the OAuth token-exchange call.
+    pattern-either:
+      - pattern: $C.fetch_token(..., verify=False, ...)
+      - pattern: $C.refresh_token(..., verify=False, ...)
+      - pattern: $C.fetch_access_token(..., verify=False, ...)
+    metadata:
+      oauthlint-rule-id: AUTH-PY-OAUTH-005
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-oauth-token-request-verify-disabled
+      category: security
+      cwe: CWE-295
+      owasp: A02:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - authlib
+        - requests-oauthlib
+      references:
+        - https://docs.authlib.org/en/latest/client/oauth2.html
+        - https://requests.readthedocs.io/en/latest/user/advanced/#ssl-cert-verification
+        - https://cwe.mitre.org/data/definitions/295.html

package/rules/rust/jwt/algorithm-confusion.yml

@@ -0,0 +1,50 @@
+rules:
+  - id: auth.rust.jwt.algorithm-confusion
+    languages:
+      - rust
+    severity: ERROR
+    message: |
+      A `jsonwebtoken` `Validation` accepts a list of algorithms that MIXES an
+      HMAC family (`Algorithm::HS256`/`HS384`/`HS512`) with an asymmetric family
+      (`Algorithm::RS*`/`ES*`/`PS*`). This is the "algorithm confusion" attack:
+      when both families are accepted, an attacker takes your RSA/EC PUBLIC key
+      (which is not secret) and signs a forged token with HS*, using the public
+      key bytes as the HMAC shared secret. `decode` then verifies that forged
+      token as valid, letting the attacker mint arbitrary identities and claims.
+
+      Pin `validation.algorithms` to a SINGLE family you actually use, e.g.
+      `validation.algorithms = vec![Algorithm::RS256];` when your issuer signs
+      with RSA, or `vec![Algorithm::HS256]` for a genuinely symmetric secret.
+      Never accept an HMAC algorithm alongside an asymmetric one.
+
+      CWE-327: use of a broken or risky cryptographic algorithm/configuration.
+    # Algorithm confusion = the accepted-algorithm list mixes an HMAC variant
+    # (HS*) with an asymmetric variant (RS*/ES*/PS*). We bind the algorithm list
+    # expression to $VEC — set either via the public `algorithms` field or via a
+    # `set_algorithms(...)` call — and require, with two ANDed metavariable-regex
+    # constraints, that its source text contains BOTH an `Algorithm::HS*` AND an
+    # `Algorithm::RS*|ES*|PS*` variant. Order-independent (no ellipsis-in-macro
+    # fragility) and inherently low-FP: a single-family list such as
+    # `vec![Algorithm::RS256]` fails the HS* constraint and is never flagged.
+    patterns:
+      - pattern-either:
+          - pattern: $V.algorithms = $VEC;
+          - pattern: $V.set_algorithms($VEC)
+      - metavariable-regex:
+          metavariable: $VEC
+          regex: '(?s).*Algorithm::HS(256|384|512)'
+      - metavariable-regex:
+          metavariable: $VEC
+          regex: '(?s).*Algorithm::(RS|ES|PS)(256|384|512)'
+    metadata:
+      oauthlint-rule-id: AUTH-RUST-JWT-006
+      oauthlint-doc-url: https://oauthlint.dev/rules/rust-jwt-algorithm-confusion
+      category: security
+      cwe: CWE-327
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - jsonwebtoken
+      references:
+        - https://cwe.mitre.org/data/definitions/327.html
+        - https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

package/rules/rust/oauth/insecure-token-endpoint.yml

@@ -0,0 +1,39 @@
+rules:
+  - id: auth.rust.oauth.insecure-token-endpoint
+    languages:
+      - rust
+    severity: ERROR
+    message: |
+      An OAuth/OIDC endpoint is being contacted over cleartext `http://`.
+      Authorization codes, `client_secret`, access/refresh tokens, and the
+      `code_verifier` then travel unencrypted — a network attacker can read
+      or rewrite them and take over the flow.
+
+      RFC 6749 §3.1 / §10.9 require TLS for the authorization and token
+      endpoints. Use `https://` for every authorize, token, and userinfo URL
+      (including the `oauth2` crate's `AuthUrl` / `TokenUrl`).
+      `http://localhost` is fine for local development and is not flagged.
+    # A string literal that targets an OAuth/OIDC endpoint over http://.
+    # Required OAuth markers keep this precise: a generic http URL is NOT
+    # flagged, only one carrying an authorize/token request or an /oauth path.
+    # `https://` cannot match, and the localhost / loopback dev hosts are
+    # subtracted below.
+    patterns:
+      - pattern-regex: |-
+          "http://[^"\s]+(?:response_type=|client_id=|client_secret=|grant_type=|code_challenge=|/oauth2?/|/connect/token|/o/oauth2|/authorize|/oauth/token)[^"]*"
+      - pattern-not-regex: |-
+          http://(?:localhost|127\.0\.0\.1|0\.0\.0\.0|\[::1\])
+    metadata:
+      oauthlint-rule-id: AUTH-RUST-OAUTH-002
+      oauthlint-doc-url: https://oauthlint.dev/rules/rust-oauth-insecure-token-endpoint
+      category: security
+      cwe: CWE-319
+      owasp: A02:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - oauth2
+        - oidc
+      references:
+        - https://datatracker.ietf.org/doc/html/rfc6749#section-3.1
+        - https://datatracker.ietf.org/doc/html/rfc6749#section-10.9
+        - https://cwe.mitre.org/data/definitions/319.html

package/rules/rust/oauth/ropc-grant.yml

@@ -0,0 +1,40 @@
+rules:
+  - id: auth.rust.oauth.ropc-grant
+    languages:
+      - rust
+    severity: ERROR
+    message: |
+      OAuth token request uses the Resource Owner Password Credentials
+      grant (`grant_type=password`). The app collects the user's password
+      and replays it to the authorization server — exactly what OAuth was
+      designed to avoid. It cannot support federation, MFA, or step-up
+      auth, and any compromise of your service exposes raw user passwords.
+
+      The OAuth 2.0 Security BCP (RFC 9700 §2.4) forbids ROPC and OAuth 2.1
+      removes it entirely. Use the authorization-code flow with PKCE
+      (`grant_type=authorization_code`) for user login, or
+      `client_credentials` for machine-to-machine. With the `oauth2` crate,
+      use `authorize_url` / `exchange_code` instead of `exchange_password`.
+    pattern-either:
+      # oauth2 crate ROPC helper — its only purpose is the password grant.
+      - pattern: $C.exchange_password(...)
+      # reqwest / hand-built form pair: ("grant_type", "password"). The value
+      # is bounded so `password_reset` and friends are not matched.
+      - pattern-regex: |-
+              "grant_type"\s*,\s*"password"
+      # URL-encoded request body string: "grant_type=password&username=…".
+      - pattern-regex: |-
+              [?&"]grant_type=password(?:[&"\s\\]|$)
+    metadata:
+      oauthlint-rule-id: AUTH-RUST-OAUTH-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/rust-oauth-ropc-grant
+      category: security
+      cwe: CWE-522
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - oauth2
+      references:
+        - https://datatracker.ietf.org/doc/html/rfc9700#section-2.4
+        - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1#section-2.4
+        - https://cwe.mitre.org/data/definitions/522.html