oauthlint-rules 0.4.0 → 0.5.1

package/rules/py/crypto/passlib-weak-scheme.yml

@@ -0,0 +1,40 @@
+rules:
+  - id: auth.py.crypto.passlib-weak-scheme
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      passlib configured with a weak or plaintext password scheme.
+
+      A `CryptContext` lists a password hashing scheme that is broken for
+      storing credentials: unsalted or fast digests (`hex_md5`, `hex_sha1`,
+      `hex_sha256`, `md5_crypt`, `ldap_md5`), legacy `des_crypt`, or outright
+      `plaintext` / `ldap_plaintext`. These are trivially brute-forced or
+      reversed, so any leaked hash exposes the underlying password (CWE-916).
+
+      Use a slow, salted, memory-hard scheme as the default, e.g.
+      `CryptContext(schemes=["argon2"])` or
+      `CryptContext(schemes=["bcrypt"])`. Keep a weak scheme only as a
+      `deprecated` verifier during migration, never as an active hashing scheme.
+    # Match the passlib `CryptContext(schemes=[...])` config where any element of
+    # the schemes list is in a CLOSED list of genuinely broken schemes. The
+    # `"$SCHEME"` string-literal metavariable captures each list element's text,
+    # and the anchored metavariable-regex matches ONLY the weak names, so modern
+    # schemes (bcrypt, argon2, scrypt, pbkdf2_sha256, ...) never fire.
+    patterns:
+      - pattern: CryptContext(..., schemes=[..., "$SCHEME", ...], ...)
+      - metavariable-regex:
+          metavariable: $SCHEME
+          regex: ^(md5_crypt|des_crypt|plaintext|hex_md5|hex_sha1|hex_sha256|ldap_md5|ldap_plaintext)$
+    metadata:
+      oauthlint-rule-id: AUTH-PY-CRYPTO-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-crypto-passlib-weak-scheme
+      category: security
+      cwe: CWE-916
+      owasp: A02:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - passlib
+      references:
+        - https://passlib.readthedocs.io/en/stable/lib/passlib.context.html
+        - https://cwe.mitre.org/data/definitions/916.html

package/rules/py/django/cors-allow-all.yml

@@ -0,0 +1,34 @@
+rules:
+  - id: auth.py.django.cors-allow-all
+    languages:
+      - python
+    severity: WARNING
+    message: |
+      django-cors-headers is configured to allow every origin, disabling
+      cross-origin access control.
+
+      `CORS_ALLOW_ALL_ORIGINS = True` (or the legacy `CORS_ORIGIN_ALLOW_ALL =
+      True`) reflects any site's `Origin`, so ANY website can make cross-origin
+      requests to your API; combined with credentialed sessions this leaks
+      cookies, tokens and CSRF protections cross-origin (CWE-942, OWASP
+      A05:2021). Set it to `False` and list trusted origins explicitly, e.g.
+      `CORS_ALLOWED_ORIGINS = ["https://app.example.com"]`.
+    # Matches ONLY the literal `True` on the django-cors-headers settings keys.
+    # `= False` and an explicit `CORS_ALLOWED_ORIGINS = [...]` allow-list are
+    # never flagged. Distinct from `auth.py.cors.allow-all`, which targets the
+    # Flask-CORS `CORS(...)` / `@cross_origin(...)` call forms.
+    pattern-either:
+      - pattern: CORS_ALLOW_ALL_ORIGINS = True
+      - pattern: CORS_ORIGIN_ALLOW_ALL = True
+    metadata:
+      oauthlint-rule-id: AUTH-PY-DJANGO-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-django-cors-allow-all
+      category: security
+      cwe: CWE-942
+      owasp: A05:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - django-cors-headers
+      references:
+        - https://github.com/adamchainz/django-cors-headers#cors_allow_all_origins-bool
+        - https://cwe.mitre.org/data/definitions/942.html

package/rules/py/drf/default-authentication-empty.yml

@@ -0,0 +1,32 @@
+rules:
+  - id: auth.py.drf.default-authentication-empty
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      DRF disables authentication globally with an empty
+      `DEFAULT_AUTHENTICATION_CLASSES` list.
+
+      An empty list means no authentication scheme runs, so `request.user` is
+      never populated from a credential and every view falls back to anonymous
+      access (CWE-306, OWASP A01:2021). Permission checks that rely on
+      `request.user` being authenticated then have nothing to enforce against.
+
+      Populate the list with the schemes you use, for example
+      `rest_framework.authentication.SessionAuthentication` and
+      `rest_framework.authentication.TokenAuthentication`.
+    # Scoped to the `REST_FRAMEWORK` settings dict; matches ONLY the empty list.
+    # A populated list such as `[SessionAuthentication]` is not matched.
+    pattern: 'REST_FRAMEWORK = {..., "DEFAULT_AUTHENTICATION_CLASSES": [], ...}'
+    metadata:
+      oauthlint-rule-id: AUTH-PY-DRF-002
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-drf-default-authentication-empty
+      category: security
+      cwe: CWE-306
+      owasp: A01:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - djangorestframework
+      references:
+        - https://www.django-rest-framework.org/api-guide/authentication/#setting-the-authentication-scheme
+        - https://cwe.mitre.org/data/definitions/306.html

package/rules/py/drf/default-permission-allowany.yml

@@ -0,0 +1,35 @@
+rules:
+  - id: auth.py.drf.default-permission-allowany
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      DRF makes every endpoint public because `DEFAULT_PERMISSION_CLASSES` is set
+      to `AllowAny`.
+
+      With `AllowAny` as the project-wide default, every view that does not
+      override `permission_classes` skips authorization entirely, so any
+      unauthenticated caller can reach it (CWE-862, OWASP A01:2021). This is easy
+      to ship by accident because it silently exposes future endpoints too.
+
+      Set the global default to a real permission such as
+      `rest_framework.permissions.IsAuthenticated` and opt specific views out to
+      public only when you mean to.
+    # Scoped to the `REST_FRAMEWORK` settings dict. Matches `AllowAny` both as the
+    # imported symbol and as the `'rest_framework.permissions.AllowAny'` string.
+    # `IsAuthenticated` (or any other class), or the key being absent, is not matched.
+    pattern-either:
+      - pattern: 'REST_FRAMEWORK = {..., "DEFAULT_PERMISSION_CLASSES": [..., AllowAny, ...], ...}'
+      - pattern: 'REST_FRAMEWORK = {..., "DEFAULT_PERMISSION_CLASSES": [..., "rest_framework.permissions.AllowAny", ...], ...}'
+    metadata:
+      oauthlint-rule-id: AUTH-PY-DRF-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-drf-default-permission-allowany
+      category: security
+      cwe: CWE-862
+      owasp: A01:2021
+      llm-prevalence: HIGH
+      technology:
+        - djangorestframework
+      references:
+        - https://www.django-rest-framework.org/api-guide/permissions/#setting-the-permission-policy
+        - https://cwe.mitre.org/data/definitions/862.html

package/rules/py/drf/view-authentication-disabled.yml

@@ -0,0 +1,34 @@
+rules:
+  - id: auth.py.drf.view-authentication-disabled
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      A DRF view disables authentication with an empty `authentication_classes`
+      list.
+
+      Setting `authentication_classes = []` on a view (or the
+      `@authentication_classes([])` decorator on a function view) turns off every
+      authentication scheme for that endpoint, so `request.user` is always
+      anonymous and any permission tied to an authenticated user cannot hold
+      (CWE-306, OWASP A01:2021).
+
+      List the schemes the view should accept, for example
+      `authentication_classes = [TokenAuthentication]`, instead of emptying it.
+    # Matches ONLY an explicitly emptied `authentication_classes`, as a class
+    # attribute or via the decorator. A populated list is not matched.
+    pattern-either:
+      - pattern: authentication_classes = []
+      - pattern: "@authentication_classes([])"
+    metadata:
+      oauthlint-rule-id: AUTH-PY-DRF-003
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-drf-view-authentication-disabled
+      category: security
+      cwe: CWE-306
+      owasp: A01:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - djangorestframework
+      references:
+        - https://www.django-rest-framework.org/api-guide/views/#api_view
+        - https://cwe.mitre.org/data/definitions/306.html

package/rules/py/flask/session-cookie-insecure.yml

@@ -0,0 +1,42 @@
+rules:
+  - id: auth.py.flask.session-cookie-insecure
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      A Flask cookie security flag is disabled through `app.config`, weakening
+      session and remember-me cookie protection.
+
+      `SESSION_COOKIE_SECURE = False` lets the session cookie travel over plain
+      HTTP where it can be sniffed on the wire, and `SESSION_COOKIE_HTTPONLY =
+      False` exposes it to JavaScript so an XSS payload can read and exfiltrate
+      it; the `REMEMBER_COOKIE_*` flags do the same for Flask-Login's long-lived
+      remember-me token (CWE-614, OWASP A05:2021). Keep these `True` (or drive
+      them from an environment check), e.g. `app.config["SESSION_COOKIE_SECURE"]
+      = True` and `app.config["SESSION_COOKIE_HTTPONLY"] = True`.
+    # Matches ONLY the literal `False` set via `app.config[...] = False` (the
+    # subscript form) or `app.config.update(...=False)` (the keyword form) — the
+    # `app.config` variants that the bare module-level assignment rule
+    # `auth.py.cookie.insecure-flags` does NOT see. `= True` and env-driven
+    # values are never flagged. `$APP` matches any Flask app variable name.
+    pattern-either:
+      - pattern: $APP.config['SESSION_COOKIE_SECURE'] = False
+      - pattern: $APP.config['SESSION_COOKIE_HTTPONLY'] = False
+      - pattern: $APP.config['REMEMBER_COOKIE_SECURE'] = False
+      - pattern: $APP.config['REMEMBER_COOKIE_HTTPONLY'] = False
+      - pattern: $APP.config.update(..., SESSION_COOKIE_SECURE=False, ...)
+      - pattern: $APP.config.update(..., REMEMBER_COOKIE_SECURE=False, ...)
+    metadata:
+      oauthlint-rule-id: AUTH-PY-FLASK-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-flask-session-cookie-insecure
+      category: security
+      cwe: CWE-614
+      owasp: A05:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - flask
+        - flask-login
+      references:
+        - https://flask.palletsprojects.com/en/stable/config/#SESSION_COOKIE_SECURE
+        - https://flask-login.readthedocs.io/en/latest/#cookie-settings
+        - https://cwe.mitre.org/data/definitions/614.html

package/rules/py/flow/insecure-random-token.yml

@@ -4,11 +4,12 @@ rules:
       - python
     severity: ERROR
     message: |
-      A security-sensitive value (token, secret, password, OTP, nonce, API key,
-      reset/verification code) is being generated with the `random` module.
-      `random` is a pseudo-random number generator seeded from predictable state
-      and is NOT cryptographically secure — its output can be predicted or
-      reproduced by an attacker, defeating the secret entirely.
+      A security-sensitive value is being generated with the `random` module.
+      The value is a token, secret, password, OTP, nonce, API key, or
+      reset/verification code. `random` is a pseudo-random number generator
+      seeded from predictable state and is NOT cryptographically secure: its
+      output can be predicted or reproduced by an attacker, defeating the
+      secret entirely.
 
       Use the `secrets` module or `os.urandom` instead:
       `secrets.token_urlsafe(32)`, `secrets.token_hex(16)`,

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

@@ -4,14 +4,15 @@ rules:
       - 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).
+      An OAuth/OIDC credential from the request flows into a logging call.
+      The tainted value is an authorization `code`, an `access_token` /
+      `refresh_token` / `id_token`, a bearer `token`, a `client_secret`, or
+      the raw `Authorization` header, and the sink is `print`, `logging.*`,
+      or a `logger.*` call. 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

package/rules/py/flow/requests-verify-disabled.yml

@@ -19,23 +19,35 @@ rules:
     # Scoped to `requests.<method>(...)`, `requests.request(...)` and Session
     # objects (`$SESSION.<method>(...)`). Fires only on the literal
     # `verify=False`; `verify=True` and `verify="/path/ca.pem"` are not flagged.
-    pattern-either:
-      - pattern: requests.get(..., verify=False, ...)
-      - pattern: requests.post(..., verify=False, ...)
-      - pattern: requests.put(..., verify=False, ...)
-      - pattern: requests.delete(..., verify=False, ...)
-      - pattern: requests.patch(..., verify=False, ...)
-      - pattern: requests.head(..., verify=False, ...)
-      - pattern: requests.options(..., verify=False, ...)
-      - pattern: requests.request(..., verify=False, ...)
-      - pattern: $SESSION.get(..., verify=False, ...)
-      - pattern: $SESSION.post(..., verify=False, ...)
-      - pattern: $SESSION.put(..., verify=False, ...)
-      - pattern: $SESSION.delete(..., verify=False, ...)
-      - pattern: $SESSION.patch(..., verify=False, ...)
-      - pattern: $SESSION.head(..., verify=False, ...)
-      - pattern: $SESSION.options(..., verify=False, ...)
-      - pattern: $SESSION.request(..., verify=False, ...)
+    patterns:
+      - pattern-either:
+          - pattern: requests.get(..., verify=$V, ...)
+          - pattern: requests.post(..., verify=$V, ...)
+          - pattern: requests.put(..., verify=$V, ...)
+          - pattern: requests.delete(..., verify=$V, ...)
+          - pattern: requests.patch(..., verify=$V, ...)
+          - pattern: requests.head(..., verify=$V, ...)
+          - pattern: requests.options(..., verify=$V, ...)
+          - pattern: requests.request(..., verify=$V, ...)
+          - pattern: $SESSION.get(..., verify=$V, ...)
+          - pattern: $SESSION.post(..., verify=$V, ...)
+          - pattern: $SESSION.put(..., verify=$V, ...)
+          - pattern: $SESSION.delete(..., verify=$V, ...)
+          - pattern: $SESSION.patch(..., verify=$V, ...)
+          - pattern: $SESSION.head(..., verify=$V, ...)
+          - pattern: $SESSION.options(..., verify=$V, ...)
+          - pattern: $SESSION.request(..., verify=$V, ...)
+      # Fire only on the literal `False` (unchanged detection), and focus the
+      # match/fix on that value token so the autofix flips just it, leaving the
+      # rest of the call intact.
+      - metavariable-regex:
+          metavariable: $V
+          regex: ^False$
+      - focus-metavariable: $V
+    # Safe, deterministic autofix: `True` is the library default (verification
+    # on) and the exact value the rule treats as compliant, so it fully resolves
+    # the finding. Only the value token is rewritten (`verify=False` -> `verify=True`).
+    fix: "True"
     metadata:
       oauthlint-rule-id: AUTH-PY-FLOW-002
       oauthlint-doc-url: https://oauthlint.dev/rules/py-flow-requests-verify-disabled

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

@@ -4,15 +4,16 @@ rules:
       - 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.
+      A JWT is decoded with an `algorithms` allowlist that mixes an HMAC algorithm with an asymmetric one.
+      The list combines 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
+      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.
 

package/rules/py/jwt/verify-claims-disabled.yml

@@ -0,0 +1,45 @@
+rules:
+  - id: auth.py.jwt.verify-claims-disabled
+    languages:
+      - python
+    severity: WARNING
+    message: |
+      PyJWT decode disables audience or issuer checks.
+
+      `jwt.decode(...)` is called with an `options` dict that turns off a claim
+      check: `"verify_aud": False`, `"verify_iss": False`, or
+      `"verify_nbf": False`. Skipping these lets a token minted for a different
+      audience or issuer (for example one from another tenant or a lower-trust
+      service) be accepted here, defeating the boundary those claims are meant
+      to enforce (CWE-347).
+
+      Remove the disabling option and validate the claim, e.g.
+      `jwt.decode(token, key, algorithms=["RS256"], audience="api",
+      issuer="https://issuer.example.com")`. PyJWT only checks `aud`/`iss` when
+      you pass the expected value, so supply it rather than disabling the check.
+    # Scoped to PyJWT's decode `options` dict. We match ONLY the aud/iss/nbf
+    # keys; `verify_signature` is reported by auth.py.jwt.no-verify and
+    # `verify_exp` by auth.py.jwt.no-expiration, so neither is matched here and
+    # we avoid duplicate findings.
+    patterns:
+      - pattern-either:
+          - pattern: jwt.decode(..., options=$OPTS, ...)
+          - pattern: decode(..., options=$OPTS, ...)
+      - metavariable-pattern:
+          metavariable: $OPTS
+          pattern-either:
+            - pattern: '{..., "verify_aud": False, ...}'
+            - pattern: '{..., "verify_iss": False, ...}'
+            - pattern: '{..., "verify_nbf": False, ...}'
+    metadata:
+      oauthlint-rule-id: AUTH-PY-JWT-008
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-jwt-verify-claims-disabled
+      category: security
+      cwe: CWE-347
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - pyjwt
+      references:
+        - https://pyjwt.readthedocs.io/en/stable/api.html#jwt.decode
+        - https://cwe.mitre.org/data/definitions/347.html

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

@@ -4,9 +4,9 @@ rules:
       - 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
+      `OAUTHLIB_INSECURE_TRANSPORT` is set, disabling oauthlib's HTTPS
+      requirement for OAuth flows. This affects `requests-oauthlib`, Authlib's
+      requests integration, and 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

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

@@ -21,10 +21,20 @@ rules:
     # `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, ...)
+    patterns:
+      - pattern-either:
+          - pattern: $C.fetch_token(..., verify=$V, ...)
+          - pattern: $C.refresh_token(..., verify=$V, ...)
+          - pattern: $C.fetch_access_token(..., verify=$V, ...)
+      # Fire only on the literal `False` (unchanged detection), and focus the
+      # match/fix on that value token so the autofix flips just it.
+      - metavariable-regex:
+          metavariable: $V
+          regex: ^False$
+      - focus-metavariable: $V
+    # Safe, deterministic autofix: `True` is the default (verification on) and the
+    # exact value the rule treats as compliant, so it resolves the finding.
+    fix: "True"
     metadata:
       oauthlint-rule-id: AUTH-PY-OAUTH-005
       oauthlint-doc-url: https://oauthlint.dev/rules/py-oauth-token-request-verify-disabled

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

@@ -4,11 +4,12 @@ rules:
       - rust
     severity: ERROR
     message: |
-      A password is being hashed with a fast, general-purpose digest (MD5 via
-      the `md5` crate, or SHA-1/SHA-256/SHA-512 via the RustCrypto `sha1`/`sha2`
-      crates). 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).
+      A password is hashed with a fast, general-purpose digest unsuitable for
+      password storage. The digest is MD5 (via the `md5` crate) or
+      SHA-1/SHA-256/SHA-512 (via the RustCrypto `sha1`/`sha2` crates). 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: Argon2 (`argon2` crate,

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

@@ -4,13 +4,14 @@ rules:
       - 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.
+      A `jsonwebtoken` `Validation` accepts both HMAC and asymmetric algorithms,
+      enabling algorithm confusion. The accepted-algorithm list MIXES an HMAC
+      family (`Algorithm::HS256`/`HS384`/`HS512`) with an asymmetric family
+      (`Algorithm::RS*`/`ES*`/`PS*`). 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

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

@@ -4,10 +4,11 @@ rules:
       - rust
     severity: ERROR
     message: |
-      A JWT HMAC signing/verification key is hardcoded as a literal in a call
-      to jsonwebtoken's `EncodingKey::from_secret` / `DecodingKey::from_secret`.
-      Anyone who can read the source or git history can forge or tamper with
-      tokens, which is a complete authentication bypass.
+      A JWT HMAC signing/verification key is hardcoded as a literal. It is
+      passed directly to jsonwebtoken's `EncodingKey::from_secret` /
+      `DecodingKey::from_secret`. Anyone who can read the source or git history
+      can forge or tamper with tokens, which is a complete authentication
+      bypass.
 
       Load the secret at runtime from the environment or a secret manager
       instead, e.g. `let key = std::env::var("JWT_SECRET")?;` followed by

package/rules/rust/jwt/no-issuer-validation.yml

@@ -4,13 +4,13 @@ rules:
       - rust
     severity: WARNING
     message: |
-      A JWT is decoded with a `jsonwebtoken` `Validation` that never sets the
-      expected issuer, so `decode` accepts a token minted by ANY issuer. The
-      `jsonwebtoken` crate does not validate the `iss` claim unless you opt in,
-      so a token signed by an attacker-controlled or otherwise untrusted issuer
-      passes validation as long as the signature checks out. For OAuth/OIDC this
-      lets a token from the wrong authorization server be replayed against this
-      API.
+      A JWT is decoded with a `jsonwebtoken` `Validation` that never sets the expected issuer.
+      Because the issuer is not pinned, `decode` accepts a token minted by ANY
+      issuer: the `jsonwebtoken` crate does not validate the `iss` claim unless
+      you opt in, so a token signed by an attacker-controlled or otherwise
+      untrusted issuer passes validation as long as the signature checks out.
+      For OAuth/OIDC this lets a token from the wrong authorization server be
+      replayed against this API.
 
       Pin the issuer before decoding, e.g.
       `validation.set_issuer(&["https://issuer.example.com"])` (or set

package/rules/session/hardcoded-secret.yml

@@ -5,9 +5,9 @@ rules:
       - typescript
     severity: ERROR
     message: |
-      An `express-session` / `cookie-session` `secret` is set to a hard-coded
-      string literal (the infamous `secret: 'keyboard cat'` is the canonical
-      AI-generated example). This key signs the session cookie: anyone who
+      An `express-session` / `cookie-session` `secret` is a hard-coded string
+      literal. The infamous `secret: 'keyboard cat'` is the canonical
+      AI-generated example. This key signs the session cookie: anyone who
       reads it from your source or git history can forge arbitrary session
       cookies and impersonate any user.
 

package/rules/session/no-regeneration.yml

@@ -5,11 +5,12 @@ rules:
       - typescript
     severity: WARNING
     message: |
-      The user is being marked as logged in (`req.session.user = ...`,
-      `req.session.userId = ...`, etc.) WITHOUT first regenerating the
-      session id. This opens the door to session-fixation attacks: an
-      attacker who plants a known session id in the victim's browser
-      before login retains access after authentication succeeds.
+      The user is marked as logged in without first regenerating the session id.
+      The identity is written onto the session (`req.session.user = ...`,
+      `req.session.userId = ...`, etc.) before the session id is rotated. This
+      opens the door to session-fixation attacks: an attacker who plants a
+      known session id in the victim's browser before login retains access
+      after authentication succeeds.
 
       Call `req.session.regenerate(cb)` (or your framework's equivalent)
       between authenticating the credentials and writing the user

package/rules/tls/reject-unauthorized.yml

@@ -5,16 +5,17 @@ rules:
       - typescript
     severity: ERROR
     message: |
-      Disabling TLS certificate validation (`rejectUnauthorized: false` or
-      `NODE_TLS_REJECT_UNAUTHORIZED=0`) makes the connection accept ANY
-      certificate, including self-signed or attacker-supplied ones. This
-      removes the protection TLS provides against man-in-the-middle attacks:
-      anyone able to intercept the network path can present a forged
-      certificate, then read and modify the traffic (credentials, tokens, data).
+      TLS certificate validation is disabled for this connection.
+      Setting `rejectUnauthorized: false` or `NODE_TLS_REJECT_UNAUTHORIZED=0`
+      makes the connection accept ANY certificate, including self-signed or
+      attacker-supplied ones. This removes the protection TLS provides against
+      man-in-the-middle attacks: anyone able to intercept the network path can
+      present a forged certificate, then read and modify the traffic
+      (credentials, tokens, data).
 
       Keep certificate validation enabled. If the server uses a private or
       self-signed CA, supply that CA explicitly instead of turning validation
-      off — e.g. `new https.Agent({ ca: fs.readFileSync('ca.pem') })`. See
+      off, e.g. `new https.Agent({ ca: fs.readFileSync('ca.pem') })`. See
       CWE-295 and the Node.js TLS docs.
     # Matches an options object literal that contains `rejectUnauthorized: false`,
     # wherever it appears (https.request, new https.Agent, tls.connect, axios