oauthlint-rules 0.1.1 → 0.2.0

package/rules/rust/flow/timing-unsafe-compare.yml

@@ -0,0 +1,77 @@
+rules:
+  - id: auth.rust.flow.timing-unsafe-compare
+    languages:
+      - rust
+    severity: WARNING
+    message: |
+      A secret-shaped value (`password`, `token`, `secret`, `apikey`,
+      `hmac`, `signature`, `mac`, `digest`) is being compared with `==` /
+      `!=`. Rust's `PartialEq` for slices and strings short-circuits on the
+      first differing byte, so the comparison time leaks the length of the
+      matching prefix — a classic timing-attack vector (CWE-208).
+
+      Use a constant-time comparison instead: `subtle::ConstantTimeEq`
+      (`a.ct_eq(b).into()`) or the `constant_time_eq` crate
+      (`constant_time_eq(a, b)`). For password verification, use a verifier
+      that compares in constant time for you (`argon2::Argon2::verify_password`,
+      `bcrypt::verify`, `scrypt`).
+    # We want to catch `provided_token == expected_token` but NOT the many
+    # legitimate non-secret comparisons that just happen to involve a
+    # variable whose name ends with one of our secret-looking suffixes:
+    #   token.len() == 32              (length check)
+    #   secret == ""                   (presence check, literal)
+    #   token.is_empty()               (presence check)
+    #   token == None / Some(_)        (option check)
+    #   username == other              (non-secret names)
+    # The pattern-not clauses below carve those out. A secret-named value
+    # compared to a *literal* is never the timing target: a literal baked
+    # into source is already public, so there is nothing to leak byte by
+    # byte.
+    pattern-either:
+      - patterns:
+          - pattern-either:
+              - pattern: $A == $B
+              - pattern: $A != $B
+          - metavariable-regex:
+              metavariable: $A
+              regex: (?i)^.*(password|passwd|secret|token|apikey|api_key|hmac|signature|mac|digest)$
+          - pattern-not: $X == "..."
+          - pattern-not: $X != "..."
+          - pattern-not: '"..." == $X'
+          - pattern-not: '"..." != $X'
+          - pattern-not: $X == None
+          - pattern-not: $X != None
+          - pattern-not: None == $X
+          - pattern-not: None != $X
+          - pattern-not: $X.len() == $N
+          - pattern-not: $X.len() != $N
+      - patterns:
+          - pattern-either:
+              - pattern: $A == $B
+              - pattern: $A != $B
+          - metavariable-regex:
+              metavariable: $B
+              regex: (?i)^.*(password|passwd|secret|token|apikey|api_key|hmac|signature|mac|digest)$
+          - pattern-not: $X == "..."
+          - pattern-not: $X != "..."
+          - pattern-not: '"..." == $X'
+          - pattern-not: '"..." != $X'
+          - pattern-not: $X == None
+          - pattern-not: $X != None
+          - pattern-not: None == $X
+          - pattern-not: None != $X
+          - pattern-not: $X.len() == $N
+          - pattern-not: $X.len() != $N
+    metadata:
+      oauthlint-rule-id: AUTH-RUST-FLOW-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/rust-flow-timing-unsafe-compare
+      category: security
+      cwe: CWE-208
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - std
+      references:
+        - https://cwe.mitre.org/data/definitions/208.html
+        - https://docs.rs/subtle/latest/subtle/
+        - https://docs.rs/constant_time_eq/latest/constant_time_eq/

package/rules/rust/jwt/disable-signature-validation.yml

@@ -0,0 +1,31 @@
+rules:
+  - id: auth.rust.jwt.disable-signature-validation
+    languages:
+      - rust
+    severity: ERROR
+    message: |
+      `Validation::insecure_disable_signature_validation()` turns off JWT
+      signature verification. Once disabled, `decode` accepts any token —
+      including ones forged or tampered with by an attacker — because the
+      cryptographic signature is never checked. For OAuth/OIDC this lets an
+      attacker mint arbitrary access tokens and identities.
+
+      Never disable signature validation. Build the validator with the
+      expected algorithm, e.g. `Validation::new(Algorithm::HS256)` (or the
+      RS/ES algorithm your issuer uses), and verify the token through
+      `decode::<Claims>(token, &key, &validation)`.
+    # Matches the insecure opt-out only. A normal `Validation` and a standard
+    # `decode(...)` are not flagged. `$V` is any validation expression.
+    pattern: $V.insecure_disable_signature_validation()
+    metadata:
+      oauthlint-rule-id: AUTH-RUST-JWT-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/rust-jwt-disable-signature-validation
+      category: security
+      cwe: CWE-347
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - jsonwebtoken
+      references:
+        - https://docs.rs/jsonwebtoken/latest/jsonwebtoken/struct.Validation.html#method.insecure_disable_signature_validation
+        - https://cwe.mitre.org/data/definitions/347.html

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

@@ -0,0 +1,41 @@
+rules:
+  - id: auth.rust.jwt.hardcoded-secret
+    languages:
+      - 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.
+
+      Load the secret at runtime from the environment or a secret manager
+      instead, e.g. `let key = std::env::var("JWT_SECRET")?;` followed by
+      `EncodingKey::from_secret(key.as_bytes())`. Never commit signing keys to
+      source control.
+    # Only literals in key position are flagged: a byte-string literal
+    # `b"..."`, or a string literal coerced with `"...".as_ref()` /
+    # `"...".as_bytes()`. Because the literal must appear directly in the
+    # argument, `from_secret(secret.as_bytes())` (a variable) and
+    # `from_secret(std::env::var("JWT_SECRET")?.as_bytes())` are NOT matched.
+    pattern-either:
+      - pattern: jsonwebtoken::EncodingKey::from_secret(b"...")
+      - pattern: jsonwebtoken::DecodingKey::from_secret(b"...")
+      - pattern: EncodingKey::from_secret(b"...")
+      - pattern: DecodingKey::from_secret(b"...")
+      - pattern: EncodingKey::from_secret("...".as_ref())
+      - pattern: DecodingKey::from_secret("...".as_ref())
+      - pattern: EncodingKey::from_secret("...".as_bytes())
+      - pattern: DecodingKey::from_secret("...".as_bytes())
+    metadata:
+      oauthlint-rule-id: AUTH-RUST-JWT-002
+      oauthlint-doc-url: https://oauthlint.dev/rules/rust-jwt-hardcoded-secret
+      category: security
+      cwe: CWE-798
+      owasp: API2:2023
+      llm-prevalence: HIGH
+      technology:
+        - jsonwebtoken
+      references:
+        - https://docs.rs/jsonwebtoken/latest/jsonwebtoken/struct.EncodingKey.html#method.from_secret
+        - https://cwe.mitre.org/data/definitions/798.html

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

@@ -0,0 +1,34 @@
+rules:
+  - id: auth.rust.jwt.no-aud-validation
+    languages:
+      - rust
+    severity: WARNING
+    message: |
+      JWT audience (`aud`) validation is disabled by setting
+      `validate_aud: false` on the `jsonwebtoken` `Validation`. With the
+      audience check turned off, a token minted for a different service is
+      accepted by `decode`, so an attacker can replay a token issued for
+      another audience against this API.
+
+      Keep `validate_aud` at its default `true` and declare the audience you
+      expect via `validation.set_audience(&["my-api"])`, so only tokens whose
+      `aud` claim matches your service are accepted.
+    # Flags the assignment `$V.validate_aud = false`. `validate_aud: true` and an
+    # omitted field are not flagged. The struct-literal form
+    # `Validation { validate_aud: false, .. }` is a known false negative:
+    # Semgrep's Rust parser cannot match a field inside a struct literal with a
+    # rest (`..`), and a text regex would false-positive on comments — kept
+    # AST-only for precision.
+    pattern: $V.validate_aud = false
+    metadata:
+      oauthlint-rule-id: AUTH-RUST-JWT-004
+      oauthlint-doc-url: https://oauthlint.dev/rules/rust-jwt-no-aud-validation
+      category: security
+      cwe: CWE-287
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - jsonwebtoken
+      references:
+        - https://docs.rs/jsonwebtoken/latest/jsonwebtoken/struct.Validation.html#structfield.validate_aud
+        - https://cwe.mitre.org/data/definitions/287.html

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

@@ -0,0 +1,35 @@
+rules:
+  - id: auth.rust.jwt.no-expiration-validation
+    languages:
+      - rust
+    severity: ERROR
+    message: |
+      JWT expiration validation is turned off by setting `validate_exp: false`
+      on the `jsonwebtoken` `Validation`. With `exp` checking disabled, `decode`
+      accepts tokens that have already expired, so a leaked or stolen access
+      token stays usable forever. For OAuth/OIDC this defeats token lifetimes
+      and revocation-by-expiry, letting an attacker replay old tokens.
+
+      Leave `validate_exp` at its default `true` so expired tokens are
+      rejected. Build the validator with `Validation::new(Algorithm::HS256)`
+      (or your issuer's algorithm) and do not turn off `validate_exp`.
+    # Matches the assignment `$V.validate_exp = false` (the idiomatic way to
+    # turn the check off after `Validation::new`). `validate_exp: true` and the
+    # field's absence (default true) are not flagged. The struct-literal form
+    # `Validation { validate_exp: false, .. }` is a known false negative:
+    # Semgrep's Rust frontend cannot match a field inside a struct literal with
+    # a rest (`..`), and a text regex would false-positive on comments — so we
+    # keep this AST-only for precision.
+    pattern: $V.validate_exp = false
+    metadata:
+      oauthlint-rule-id: AUTH-RUST-JWT-003
+      oauthlint-doc-url: https://oauthlint.dev/rules/rust-jwt-no-expiration-validation
+      category: security
+      cwe: CWE-613
+      owasp: API2:2023
+      llm-prevalence: MEDIUM
+      technology:
+        - jsonwebtoken
+      references:
+        - https://docs.rs/jsonwebtoken/latest/jsonwebtoken/struct.Validation.html#structfield.validate_exp
+        - https://cwe.mitre.org/data/definitions/613.html

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

@@ -0,0 +1,30 @@
+rules:
+  - id: auth.rust.tls.accept-invalid-certs
+    languages:
+      - rust
+    severity: ERROR
+    message: |
+      A reqwest client is built with `danger_accept_invalid_certs(true)`, which
+      turns off TLS certificate validation. Any attacker who can intercept the
+      connection can present any certificate and read or tamper with the
+      traffic — a man-in-the-middle hole. For OAuth/OIDC this leaks
+      authorization codes, access tokens, and client secrets in transit.
+
+      Never accept invalid certificates. Leave validation on (the default). To
+      trust a private CA in development, add it explicitly with
+      `ClientBuilder::add_root_certificate(cert)` instead.
+    # 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)
+    metadata:
+      oauthlint-rule-id: AUTH-RUST-TLS-001
+      oauthlint-doc-url: https://oauthlint.dev/rules/rust-tls-accept-invalid-certs
+      category: security
+      cwe: CWE-295
+      owasp: A02:2021
+      llm-prevalence: HIGH
+      technology:
+        - reqwest
+      references:
+        - https://docs.rs/reqwest/latest/reqwest/struct.ClientBuilder.html#method.danger_accept_invalid_certs
+        - https://cwe.mitre.org/data/definitions/295.html

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

@@ -0,0 +1,32 @@
+rules:
+  - id: auth.rust.tls.accept-invalid-hostnames
+    languages:
+      - rust
+    severity: ERROR
+    message: |
+      A reqwest client is built with `danger_accept_invalid_hostnames(true)`,
+      which turns off TLS hostname verification. The certificate chain is still
+      checked, but a certificate valid for any other domain is accepted for this
+      connection — so an attacker holding a valid certificate for a host they
+      control can intercept the connection and read or tamper with the traffic,
+      a man-in-the-middle hole. For OAuth/OIDC this leaks authorization codes,
+      access tokens, and client secrets in transit.
+
+      Never accept invalid hostnames. Leave hostname verification on (the
+      default). To trust a private CA in development, add it explicitly with
+      `ClientBuilder::add_root_certificate(cert)` instead.
+    # 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)
+    metadata:
+      oauthlint-rule-id: AUTH-RUST-TLS-002
+      oauthlint-doc-url: https://oauthlint.dev/rules/rust-tls-accept-invalid-hostnames
+      category: security
+      cwe: CWE-297
+      owasp: A02:2021
+      llm-prevalence: HIGH
+      technology:
+        - reqwest
+      references:
+        - https://docs.rs/reqwest/latest/reqwest/struct.ClientBuilder.html#method.danger_accept_invalid_hostnames
+        - https://cwe.mitre.org/data/definitions/297.html

package/rules/secret/public-env-secret.yml

@@ -0,0 +1,58 @@
+rules:
+  - id: auth.secret.public-env-secret
+    languages:
+      - javascript
+      - typescript
+    severity: ERROR
+    message: |
+      A secret is being read from an environment variable whose name carries a
+      client-public prefix. Bundlers inline these variables into the browser
+      JavaScript at build time:
+
+        - Next.js / webpack:        NEXT_PUBLIC_*
+        - Create React App:         REACT_APP_*
+        - Gatsby:                   GATSBY_*
+        - SvelteKit / generic:      PUBLIC_*
+        - Vite:                     VITE_*  (via import.meta.env)
+
+      Anything carried by such a variable ships to every visitor — a secret,
+      token, password, or private key placed here is published, not protected.
+
+      Keep the secret in a server-only variable (no public prefix) and read it
+      only in server code (API routes, server actions, loaders). If a value is
+      genuinely safe to expose (publishable key, client_id), name it so.
+    # We deliberately match only the suffixes that are NEVER legitimately
+    # public — SECRET, PASSWORD, PRIVATE(_KEY). `API_KEY` / `TOKEN` are
+    # excluded on purpose: many services ship *publishable* client keys and
+    # public tokens under a public prefix (Stripe publishable key, Mapbox
+    # token, Algolia search key, Inkeep widget key), so flagging those would
+    # be a false positive on legitimate code. The trade-off is recall on a
+    # genuinely-secret `NEXT_PUBLIC_*_API_KEY`; precision wins here.
+    pattern-either:
+      # process.env.<PUBLIC_PREFIX>...<SECRET_SUFFIX>
+      - patterns:
+          - pattern: process.env.$VAR
+          - metavariable-regex:
+              metavariable: $VAR
+              regex: ^(NEXT_PUBLIC|REACT_APP|GATSBY|PUBLIC)_.*(SECRET|PRIVATE|PASSWORD).*$
+      # import.meta.env.<VITE_PREFIX>...<SECRET_SUFFIX>
+      - patterns:
+          - pattern: import.meta.env.$VAR
+          - metavariable-regex:
+              metavariable: $VAR
+              regex: ^VITE_.*(SECRET|PRIVATE|PASSWORD).*$
+    metadata:
+      oauthlint-rule-id: AUTH-SECRET-002
+      oauthlint-doc-url: https://oauthlint.dev/rules/secret-public-env-secret
+      category: security
+      cwe: CWE-200
+      owasp: A02:2021
+      llm-prevalence: HIGH
+      technology:
+        - next.js
+        - vite
+        - create-react-app
+      references:
+        - https://nextjs.org/docs/app/building-your-application/configuring/environment-variables#bundling-environment-variables-for-the-browser
+        - https://vitejs.dev/guide/env-and-mode#env-variables
+        - https://owasp.org/Top10/A02_2021-Cryptographic_Failures/

package/rules/session/hardcoded-secret.yml

@@ -0,0 +1,42 @@
+rules:
+  - id: auth.session.hardcoded-secret
+    languages:
+      - javascript
+      - 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
+      reads it from your source or git history can forge arbitrary session
+      cookies and impersonate any user.
+
+      Load the secret from the environment (`process.env.SESSION_SECRET`) or a
+      secret manager, and rotate it out of source control. Add a placeholder
+      to `.env.example` so contributors know it is required.
+    # AST patterns target the `secret:` key inside session()/cookieSession()
+    # options. The metavariable-pattern requires $S to be a quoted literal, so
+    # `process.env.SESSION_SECRET`, `config.sessionSecret`, and `loadSecret()`
+    # never match (they are not string literals).
+    patterns:
+      - pattern-either:
+          - pattern: 'session({secret: $S, ...})'
+          - pattern: 'cookieSession({secret: $S, ...})'
+          - pattern: 'expressSession({secret: $S, ...})'
+      - metavariable-pattern:
+          metavariable: $S
+          patterns:
+            - pattern-regex: ^['"].*['"]$
+    metadata:
+      oauthlint-rule-id: AUTH-SESSION-003
+      oauthlint-doc-url: https://oauthlint.dev/rules/session-hardcoded-secret
+      category: security
+      cwe: CWE-798
+      owasp: A07:2021
+      llm-prevalence: HIGH
+      technology:
+        - express-session
+        - cookie-session
+      references:
+        - https://github.com/expressjs/session#secret
+        - https://cwe.mitre.org/data/definitions/798.html