oauthlint-rules 0.2.2 → 0.2.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oauthlint-rules",
-  "version": "0.2.2",
+  "version": "0.2.4",
   "description": "Semgrep rules catching the OAuth/OIDC/JWT anti-patterns that AI coding tools systematically produce.",
   "type": "module",
   "main": "./dist/index.js",

package/rules/cookie/samesite-none-insecure.yml

@@ -0,0 +1,50 @@
+rules:
+  - id: auth.cookie.samesite-none-insecure
+    languages:
+      - javascript
+      - typescript
+    severity: WARNING
+    message: |
+      A cookie is being set with `SameSite=None` but WITHOUT `Secure`.
+      `SameSite=None` *requires* `Secure`: modern browsers reject a
+      `SameSite=None` cookie that is not also `Secure`, so the cookie is
+      silently dropped. Worse, if anything does accept it, the cookie is a
+      cross-site cookie travelling over plaintext — it can be sent over plain
+      HTTP and offers no CSRF protection at all.
+
+      Fix: add `secure: true`, and only use `SameSite=None` when you genuinely
+      need the cookie sent on cross-site requests; otherwise prefer
+      `SameSite=Strict` or `Lax`. See CWE-1275.
+    pattern-either:
+      # An options object that sets sameSite: 'none' (any casing) but does NOT
+      # also set secure: true. The `pattern-not` requires the ABSENCE of
+      # `secure: true`, which covers both "secure omitted entirely" and the
+      # explicit `secure: false` case — neither satisfies the negation.
+      - patterns:
+          - pattern-either:
+              - pattern: "{..., sameSite: 'none', ...}"
+              - pattern: '{..., sameSite: "none", ...}'
+              - pattern: "{..., sameSite: 'None', ...}"
+              - pattern: '{..., sameSite: "None", ...}'
+          - pattern-not: '{..., secure: true, ...}'
+      # Raw Set-Cookie header string carrying SameSite=None with no Secure
+      # attribute. We match the whole quoted/backtick cookie string so the
+      # Secure check spans the *entire* string (Secure may legitimately appear
+      # before OR after SameSite=None) rather than the narrow `SameSite=None`
+      # span. The negative lookahead `(?!...secure)` is anchored at the opening
+      # quote, so it fails the match if a `secure` attribute appears anywhere
+      # inside the literal — leaving only SameSite=None strings that lack it.
+      - pattern-regex: '(?i)(["''`])(?![^"''`\n]*\bsecure\b)[^"''`\n]*\bsamesite\s*=\s*none\b[^"''`\n]*\1'
+    metadata:
+      oauthlint-rule-id: AUTH-COOKIE-005
+      oauthlint-doc-url: https://oauthlint.dev/rules/cookie-samesite-none-insecure
+      category: security
+      cwe: CWE-1275
+      owasp: A05:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - express
+        - cookie
+      references:
+        - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite#samesitenone_requires_secure
+        - https://cwe.mitre.org/data/definitions/1275.html

package/rules/go/jwt/skip-claims-validation.yml

@@ -0,0 +1,36 @@
+rules:
+  - id: auth.go.jwt.skip-claims-validation
+    languages:
+      - go
+    severity: WARNING
+    message: |
+      A JWT parser is configured with `jwt.WithoutClaimsValidation()`, which
+      turns OFF the standard registered-claims validation golang-jwt performs by
+      default — the `exp` (expiry), `nbf` (not-before) and `iat` (issued-at)
+      checks. With validation disabled an expired or not-yet-valid token still
+      parses successfully, so a stolen or long-expired token is accepted as if
+      it were current (CWE-613).
+
+      Remove `jwt.WithoutClaimsValidation()` and let golang-jwt validate the
+      time-based claims. If a specific claim must be relaxed, scope it narrowly
+      (e.g. `jwt.WithLeeway(...)`) instead of disabling all claims validation.
+    # Presence-based: `jwt.WithoutClaimsValidation()` is a parser option whose
+    # only purpose is to disable claims validation, so matching the call
+    # expression anywhere it is passed (to `jwt.Parse`, `jwt.ParseWithClaims`
+    # or `jwt.NewParser`) is unambiguous and low false-positive. Normal
+    # `jwt.Parse(...)` / `jwt.ParseWithClaims(...)` calls without the option are
+    # NOT matched. `jwt` is the golang-jwt/jwt/v5 import used in the sibling
+    # rules.
+    pattern: jwt.WithoutClaimsValidation()
+    metadata:
+      oauthlint-rule-id: AUTH-GO-JWT-005
+      oauthlint-doc-url: https://oauthlint.dev/rules/go-jwt-skip-claims-validation
+      category: security
+      cwe: CWE-613
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - golang-jwt
+      references:
+        - https://pkg.go.dev/github.com/golang-jwt/jwt/v5#ParserOption
+        - https://cwe.mitre.org/data/definitions/613.html

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

@@ -0,0 +1,41 @@
+rules:
+  - id: auth.java.crypto.weak-hash
+    languages:
+      - java
+    severity: WARNING
+    message: |
+      A broken hash algorithm (MD5 or SHA-1) is being instantiated via JCA
+      `MessageDigest.getInstance(...)`. MD5 and SHA-1 are cryptographically
+      broken: practical collision attacks exist, so they must NOT be used for
+      any security purpose — integrity checks, content/token fingerprints,
+      digital signatures, HMAC keys, or deduplication that a trust decision
+      depends on (CWE-328 / CWE-327).
+
+      Use SHA-256 or stronger (SHA-384, SHA-512, SHA-3):
+      `MessageDigest.getInstance("SHA-256")`. Note: this rule covers the general
+      weak-digest case; storing *passwords* needs a dedicated slow hasher
+      (BCrypt/Argon2/PBKDF2), which is enforced separately.
+    # Match only the algorithm string passed to MessageDigest.getInstance(...).
+    # The metavariable-regex flags the broken digests MD5, SHA-1 and the SHA1
+    # alias (case-insensitive, optional hyphen). It is scoped to the
+    # getInstance(...) instantiation site on purpose so it is low-FP and does
+    # NOT overlap auth.java.crypto.weak-password-hash, which instead anchors on
+    # a password-named digest()/update() call (and also flags SHA-256/SHA-512 in
+    # that password context). "SHA-256"/"SHA-512" are silent here.
+    patterns:
+      - pattern: java.security.MessageDigest.getInstance($ALG, ...)
+      - metavariable-regex:
+          metavariable: $ALG
+          regex: (?i)^"(md5|sha-?1)"$
+    metadata:
+      oauthlint-rule-id: AUTH-JAVA-CRYPTO-004
+      oauthlint-doc-url: https://oauthlint.dev/rules/java-crypto-weak-hash
+      category: security
+      cwe: CWE-328
+      owasp: A02:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - java
+      references:
+        - https://cwe.mitre.org/data/definitions/328.html
+        - https://csrc.nist.gov/news/2022/nist-transitioning-away-from-sha-1-for-all-apps

package/rules/jwt/ignore-expiration.yml

@@ -0,0 +1,43 @@
+rules:
+  - id: auth.jwt.ignore-expiration
+    languages:
+      - javascript
+      - typescript
+    severity: WARNING
+    message: |
+      `jwt.verify(token, key, { ignoreExpiration: true })` from `jsonwebtoken`
+      disables the `exp` (expiry) claim check, so an expired token is accepted
+      as valid forever. A stolen or long-old token then never stops working,
+      defeating the whole point of short-lived access tokens.
+
+      Remove `ignoreExpiration: true` so the `exp` claim is enforced, and set a
+      sane `expiresIn` when signing (`jwt.sign(payload, key, { expiresIn: '15m'
+      })`). See CWE-613 (Insufficient Session Expiration).
+    # Scoped to the `jsonwebtoken` library via the common alias `jwt`, mirroring
+    # decode-without-verify.yml. We only flag `verify(...)` calls that explicitly
+    # pass `ignoreExpiration: true`; `verify(...)` without that option, and
+    # `ignoreExpiration: false`, are never matched. We also support the
+    # destructured import `import { verify } from 'jsonwebtoken'`, scoped to that
+    # import so an unrelated `verify()` is safe. The options object is matched
+    # with `{ ..., ignoreExpiration: true, ... }` so the flag is caught
+    # regardless of which other options (algorithms, maxAge, audience, ...)
+    # appear alongside it.
+    pattern-either:
+      - pattern: 'jwt.verify($T, $K, { ..., ignoreExpiration: true, ... })'
+      - patterns:
+          - pattern-inside: |
+              import { ..., verify, ... } from 'jsonwebtoken'
+              ...
+          - pattern: 'verify($T, $K, { ..., ignoreExpiration: true, ... })'
+    metadata:
+      oauthlint-rule-id: AUTH-JWT-011
+      oauthlint-doc-url: https://oauthlint.dev/rules/jwt-ignore-expiration
+      category: security
+      cwe: CWE-613
+      owasp: API2:2023
+      llm-prevalence: HIGH
+      technology:
+        - jsonwebtoken
+      references:
+        - https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback
+        - https://cwe.mitre.org/data/definitions/613.html

package/rules/oauth/access-token-in-url.yml

@@ -0,0 +1,39 @@
+rules:
+  - id: auth.oauth.access-token-in-url
+    languages:
+      - javascript
+      - typescript
+    severity: WARNING
+    message: |
+      An OAuth `access_token` (or `refresh_token` / `id_token`) is placed in a
+      URL query string. URLs leak: the full URL — token included — is recorded
+      in server and reverse-proxy access logs, saved in browser history, and
+      sent in the `Referer` header to every third-party CDN, analytics, and ad
+      script loaded by the destination page. A token in a URL is a leaked token.
+
+      Send the token in the `Authorization: Bearer …` header, or in a POST
+      request body. Never in the URL query string.
+
+      CWE-598: Use of GET Request Method With Sensitive Query Strings.
+    # Anchored to the query-param shape `?<name>=` / `&<name>=` (the `[?&]…=`
+    # form) so we fire on token-carrying URLs built as string or template
+    # literals, while staying silent on: a token in an `Authorization` header,
+    # a POST body / object property `{ access_token: t }` (no leading `?`/`&`
+    # and no trailing `=`), `params.set('access_token', …)` builders, and the
+    # bare word `access_token` in a comment or non-URL string. Case-insensitive
+    # on the param name. This is deliberately distinct from
+    # auth.flow.credentials-in-url (which excludes `access_token`) and
+    # auth.jwt.in-url (which only matches JWT-shaped `eyJ…` values).
+    pattern-regex: '[?&](?i:access_token|refresh_token|id_token)='
+    metadata:
+      oauthlint-rule-id: AUTH-OAUTH-013
+      oauthlint-doc-url: https://oauthlint.dev/rules/oauth-access-token-in-url
+      category: security
+      cwe: CWE-598
+      owasp: A05:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - oauth
+      references:
+        - https://owasp.org/Top10/A05_2021-Security_Misconfiguration/
+        - https://cwe.mitre.org/data/definitions/598.html

package/rules/oauth/token-in-localstorage.yml

@@ -0,0 +1,74 @@
+rules:
+  - id: auth.oauth.token-in-localstorage
+    languages:
+      - javascript
+      - typescript
+    severity: WARNING
+    message: |
+      An OAuth/OIDC token is being written to `localStorage` /
+      `sessionStorage` under a token-named key (`access_token`,
+      `refresh_token`, `id_token`, …). Web storage is readable by any
+      script on the origin, so any XSS — including a compromised
+      third-party dependency — can exfiltrate the token via
+      `getItem(...)`. There is no browser-side mitigation, unlike
+      `HttpOnly` cookies.
+
+      Keep access/refresh/id tokens in memory only, or have the server
+      issue them in a `Secure; HttpOnly; SameSite=Strict` cookie.
+      `sessionStorage` is no safer than `localStorage` against XSS — it
+      grants the same attacker capability.
+
+      See CWE-922: Insecure Storage of Sensitive Information.
+    # We scope to common OAuth token KEY NAMES (case-insensitively) so this
+    # stays low-FP: `localStorage.setItem("theme", …)` and other non-token
+    # keys are NOT flagged. The key is bound to a metavariable and constrained
+    # with metavariable-regex `(?i)(access|refresh|id)[_-]?token`, which matches
+    # access_token / refresh_token / id_token and the camelCase accessToken /
+    # refreshToken / idToken. This deliberately overlaps as little as possible
+    # with auth.jwt.localstorage, which keys off the strong word `token`/`jwt`
+    # in either key or value (incl. variable keys); this rule is presence-based
+    # on a fixed set of OAuth/OIDC token key names.
+    pattern-either:
+      # setItem("access_token", v) on localStorage / sessionStorage.
+      - patterns:
+          - pattern-either:
+              - pattern: localStorage.setItem("$KEY", $V)
+              - pattern: sessionStorage.setItem("$KEY", $V)
+              - pattern: window.localStorage.setItem("$KEY", $V)
+              - pattern: window.sessionStorage.setItem("$KEY", $V)
+          - metavariable-regex:
+              metavariable: $KEY
+              regex: (?i)^(access|refresh|id)[_-]?token$
+      # Property assignment: localStorage.accessToken = v
+      - patterns:
+          - pattern-either:
+              - pattern: localStorage.$KEY = $V
+              - pattern: sessionStorage.$KEY = $V
+              - pattern: window.localStorage.$KEY = $V
+              - pattern: window.sessionStorage.$KEY = $V
+          - metavariable-regex:
+              metavariable: $KEY
+              regex: (?i)^(access|refresh|id)[_-]?token$
+      # Bracket assignment: localStorage["access_token"] = v
+      - patterns:
+          - pattern-either:
+              - pattern: localStorage["$KEY"] = $V
+              - pattern: sessionStorage["$KEY"] = $V
+              - pattern: window.localStorage["$KEY"] = $V
+              - pattern: window.sessionStorage["$KEY"] = $V
+          - metavariable-regex:
+              metavariable: $KEY
+              regex: (?i)^(access|refresh|id)[_-]?token$
+    metadata:
+      oauthlint-rule-id: AUTH-OAUTH-012
+      oauthlint-doc-url: https://oauthlint.dev/rules/oauth-token-in-localstorage
+      category: security
+      cwe: CWE-922
+      owasp: A05:2021
+      llm-prevalence: HIGH
+      technology:
+        - localStorage
+        - sessionStorage
+      references:
+        - https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html#local-storage
+        - https://cwe.mitre.org/data/definitions/922.html

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

@@ -0,0 +1,55 @@
+rules:
+  - id: auth.py.cors.allow-all
+    languages:
+      - python
+    severity: ERROR
+    message: |
+      Flask-CORS is configured with `supports_credentials=True` together with a
+      wildcard origin (`origins="*"`, `origins=["*"]`, or — since Flask-CORS
+      defaults to `*` — no `origins` argument at all). The CORS spec forbids the
+      `Access-Control-Allow-Origin: *` + `Access-Control-Allow-Credentials: true`
+      combination, so browsers will block it; the dangerous "fix" is to leave the
+      wildcard in place while keeping credentials on, which exposes credentialed
+      cross-origin access to ANY website (CWE-942). For OAuth/OIDC this leaks
+      cookies, session tokens and CSRF protections cross-origin.
+
+      Credentialed requests must use an explicit allow-list of trusted origins,
+      e.g. `CORS(app, origins=["https://app.example.com"], supports_credentials=True)`.
+      If you genuinely need a public, wildcard endpoint, drop credentials:
+      `CORS(app, origins="*")` (the default, `supports_credentials=False`).
+    # Match presence of `supports_credentials=True` paired with a wildcard origin
+    # (`origins="*"` / `origins=["*"]`) OR no `origins` argument (Flask-CORS then
+    # defaults to `*`). The explicit-wildcard arms fire on `CORS(...)` and the
+    # `@cross_origin(...)` decorator; the default-wildcard arm uses `pattern-not`
+    # to require that NO `origins=...` is present, so an explicit allow-list such
+    # as `origins=["https://app.example.com"]` is never flagged.
+    pattern-either:
+      # Explicit wildcard origin + credentials — CORS(...) call.
+      - pattern: CORS(..., origins="*", ..., supports_credentials=True, ...)
+      - pattern: CORS(..., supports_credentials=True, ..., origins="*", ...)
+      - pattern: CORS(..., origins=["*"], ..., supports_credentials=True, ...)
+      - pattern: CORS(..., supports_credentials=True, ..., origins=["*"], ...)
+      # Explicit wildcard origin + credentials — @cross_origin(...) decorator.
+      - pattern: '@cross_origin(..., origins="*", ..., supports_credentials=True, ...)'
+      - pattern: '@cross_origin(..., supports_credentials=True, ..., origins="*", ...)'
+      - pattern: '@cross_origin(..., origins=["*"], ..., supports_credentials=True, ...)'
+      - pattern: '@cross_origin(..., supports_credentials=True, ..., origins=["*"], ...)'
+      # Credentials on, NO origins argument → Flask-CORS defaults to wildcard.
+      - patterns:
+          - pattern: CORS(..., supports_credentials=True, ...)
+          - pattern-not: CORS(..., origins=$ORIGINS, ...)
+      - patterns:
+          - pattern: '@cross_origin(..., supports_credentials=True, ...)'
+          - pattern-not: '@cross_origin(..., origins=$ORIGINS, ...)'
+    metadata:
+      oauthlint-rule-id: AUTH-PY-CORS-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-cors-allow-all
+      category: security
+      cwe: CWE-942
+      owasp: A05:2021
+      llm-prevalence: MEDIUM
+      technology:
+        - flask-cors
+      references:
+        - https://flask-cors.readthedocs.io/en/latest/configuration.html
+        - https://cwe.mitre.org/data/definitions/942.html

package/rules/py/jwt/no-expiration.yml

@@ -0,0 +1,36 @@
+rules:
+  - id: auth.py.jwt.no-expiration
+    languages:
+      - python
+    severity: WARNING
+    message: |
+      A JWT is decoded with `options={"verify_exp": False}`, which turns off
+      PyJWT's `exp` (expiration) check. With expiry verification disabled, an
+      expired — or stolen and long-since-revoked — token is still accepted, so
+      tokens effectively never expire.
+
+      Remove the `"verify_exp": False` option; PyJWT verifies `exp` by default,
+      e.g. `jwt.decode(token, key, algorithms=["RS256"])`. If a token legitimately
+      carries no `exp`, prefer `options={"require": ["exp"]}` to mandate one.
+    # Scoped to PyJWT's `jwt.decode(...)`. Matches the `options` dict containing
+    # `"verify_exp": False`, covering both `jwt.decode(...)` and a destructured
+    # `from jwt import decode` -> `decode(..., options=...)` call shape.
+    patterns:
+      - pattern-either:
+          - pattern: jwt.decode(..., options=$OPTS, ...)
+          - pattern: decode(..., options=$OPTS, ...)
+      - metavariable-pattern:
+          metavariable: $OPTS
+          pattern: '{..., "verify_exp": False, ...}'
+    metadata:
+      oauthlint-rule-id: AUTH-PY-JWT-005
+      oauthlint-doc-url: https://oauthlint.dev/rules/py-jwt-no-expiration
+      category: security
+      cwe: CWE-613
+      owasp: API2:2023
+      llm-prevalence: HIGH
+      technology:
+        - PyJWT
+      references:
+        - https://pyjwt.readthedocs.io/en/stable/api.html#jwt.decode
+        - https://cwe.mitre.org/data/definitions/613.html

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

@@ -0,0 +1,59 @@
+rules:
+  - id: auth.rust.jwt.no-issuer-validation
+    languages:
+      - 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.
+
+      Pin the issuer before decoding, e.g.
+      `validation.set_issuer(&["https://issuer.example.com"])` (or set
+      `validation.iss`), so only tokens whose `iss` claim matches your trusted
+      authorization server are accepted.
+    # Modeled on auth.rust.jwt.no-aud-validation: detect a `Validation`
+    # (`Validation::new(...)` or `Validation::default()`) that flows into
+    # `decode(...)` but never has its issuer pinned. Unlike `aud`/`exp` (default
+    # `true`, disabled via `validate_* = false`), the issuer check is OFF by
+    # default and must be opted into via `set_issuer(...)` / `validation.iss`,
+    # so the vulnerable shape is the ABSENCE of that call. We bind the validator
+    # to `$V` at construction, require a `decode` that uses it, and suppress the
+    # finding with `pattern-not-inside` when `set_issuer` / `validation.iss` is
+    # set on the same `$V`. Matching on the construction (not the `decode` call)
+    # mirrors the sibling rule's low-FP, AST-only profile.
+    patterns:
+      - pattern-either:
+          - pattern: let mut $V = Validation::new(...);
+          - pattern: let mut $V = Validation::default();
+      - pattern-not-inside: |
+          let mut $V = ...;
+          ...
+          $V.set_issuer(...);
+          ...
+      - pattern-not-inside: |
+          let mut $V = ...;
+          ...
+          $V.iss = $X;
+          ...
+      - pattern-inside: |
+          let mut $V = ...;
+          ...
+          decode($TOKEN, $KEY, &$V)
+    metadata:
+      oauthlint-rule-id: AUTH-RUST-JWT-005
+      oauthlint-doc-url: https://oauthlint.dev/rules/rust-jwt-no-issuer-validation
+      category: security
+      cwe: CWE-345
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - jsonwebtoken
+      references:
+        - https://docs.rs/jsonwebtoken/latest/jsonwebtoken/struct.Validation.html#method.set_issuer
+        - https://cwe.mitre.org/data/definitions/345.html
+        - https://cwe.mitre.org/data/definitions/287.html

package/rules/rust/tls/accept-invalid-certs.yml

@@ -16,6 +16,11 @@ rules:
     # Matches only the literal `true`. `danger_accept_invalid_certs(false)` and
     # the method's absence are not flagged. `$B` is any builder expression.
     pattern: $B.danger_accept_invalid_certs(true)
+    # Safe, deterministic autofix: flip the boolean literal to `false`, which is
+    # the secure default and fully resolves the finding. `$B` (the builder
+    # expression) is preserved verbatim, so the surrounding chain is untouched —
+    # only `true` -> `false` changes.
+    fix: $B.danger_accept_invalid_certs(false)
     metadata:
       oauthlint-rule-id: AUTH-RUST-TLS-001
       oauthlint-doc-url: https://oauthlint.dev/rules/rust-tls-accept-invalid-certs

package/rules/rust/tls/accept-invalid-hostnames.yml

@@ -18,6 +18,11 @@ rules:
     # Matches only the literal `true`. `danger_accept_invalid_hostnames(false)`
     # and the method's absence are not flagged. `$B` is any builder expression.
     pattern: $B.danger_accept_invalid_hostnames(true)
+    # Safe, deterministic autofix: flip the boolean literal to `false`, which is
+    # the secure default and fully resolves the finding. `$B` (the builder
+    # expression) is preserved verbatim, so the surrounding chain is untouched —
+    # only `true` -> `false` changes.
+    fix: $B.danger_accept_invalid_hostnames(false)
     metadata:
       oauthlint-rule-id: AUTH-RUST-TLS-002
       oauthlint-doc-url: https://oauthlint.dev/rules/rust-tls-accept-invalid-hostnames

package/rules/tls/reject-unauthorized.yml

@@ -0,0 +1,42 @@
+rules:
+  - id: auth.tls.reject-unauthorized
+    languages:
+      - javascript
+      - 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).
+
+      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
+      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
+    # `httpsAgent`, node-fetch `agent`, etc.). `rejectUnauthorized` is a
+    # TLS-specific key, so matching the literal directly is very low FP. We also
+    # flag setting the global escape hatch `NODE_TLS_REJECT_UNAUTHORIZED` to "0".
+    # `rejectUnauthorized: true` and objects without the key are never matched.
+    pattern-either:
+      - pattern: '{..., rejectUnauthorized: false, ...}'
+      - pattern: 'process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0"'
+      - pattern: "process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'"
+    metadata:
+      oauthlint-rule-id: AUTH-TLS-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/tls-reject-unauthorized
+      category: security
+      cwe: CWE-295
+      owasp: A05:2021
+      llm-prevalence: HIGH
+      technology:
+        - node
+        - https
+        - axios
+      references:
+        - https://nodejs.org/api/tls.html#tlsconnectoptions-callback
+        - https://cwe.mitre.org/data/definitions/295.html