codeintely-cli 0.1.0__py3-none-any.whl

codeintely_cli/rules/identity_security.yaml

@@ -0,0 +1,691 @@
+rules:
+  # --- IDOR / BOLA / tenant isolation --------------------------------------
+
+  - id: django-get-object-or-404-missing-tenant-filter
+    languages: [python]
+    severity: WARNING
+    message: >-
+      `get_object_or_404` looks up this model by id/pk alone, with no
+      tenant/org/user scoping in the same call. In a multi-tenant app this is
+      a direct IDOR: any authenticated user can fetch another tenant's row by
+      guessing/incrementing the id. Add the caller's tenant/owner as an extra
+      keyword argument, e.g. `get_object_or_404(Invoice, pk=pk,
+      organization=request.user.organization)`. (Heuristic rule — expect some
+      false positives on genuinely single-tenant/global models.)
+    metadata:
+      owasp_category: "A01:2021 - Broken Access Control"
+      cwe: "CWE-639"
+      internal_severity: HIGH
+    patterns:
+      - pattern-either:
+          - pattern: get_object_or_404($MODEL, pk=$PK)
+          - pattern: get_object_or_404($MODEL, id=$ID)
+
+  - id: drf-viewset-queryset-not-scoped-to-user
+    languages: [python]
+    severity: WARNING
+    message: >-
+      This DRF ViewSet's `queryset` class attribute is a bare `.all()` with
+      no `get_queryset()` override to scope it to the requesting user/tenant.
+      DRF's generic list/retrieve/update/destroy actions read straight from
+      `self.queryset` — every row in the table is reachable by any
+      authenticated caller, not just their own tenant's. Override
+      `get_queryset()` to filter by `self.request.user` (or their
+      organization) instead of declaring `queryset` directly.
+    metadata:
+      owasp_category: "A01:2021 - Broken Access Control"
+      cwe: "CWE-639"
+      internal_severity: HIGH
+    patterns:
+      - pattern: |
+          class $VIEW(...):
+              ...
+              queryset = $MODEL.objects.all()
+              ...
+      - pattern-not: |
+          class $VIEW(...):
+              ...
+              def get_queryset(self):
+                  ...
+      - metavariable-regex:
+          metavariable: $VIEW
+          regex: ".*(ViewSet|View)$"
+
+  - id: drf-get-queryset-returns-unscoped-all
+    languages: [python]
+    severity: WARNING
+    message: >-
+      `get_queryset()` returns `.all()` directly with no visible filter by
+      the requesting user/tenant. This is the one place DRF expects
+      per-request scoping to happen — returning the whole table here defeats
+      that, exposing every tenant's rows to every authenticated caller. Filter
+      by `self.request.user` or their organization before returning.
+    metadata:
+      owasp_category: "A01:2021 - Broken Access Control"
+      cwe: "CWE-639"
+      internal_severity: HIGH
+    patterns:
+      - pattern: |
+          def get_queryset(self):
+              return $MODEL.objects.all()
+
+  - id: fastapi-sqlalchemy-query-missing-ownership-filter
+    languages: [python]
+    severity: WARNING
+    message: >-
+      This SQLAlchemy query filters only by id with no owner/tenant column
+      in the same filter chain. A caller who can reach this route with any
+      authenticated identity can read/modify another user's or tenant's row
+      by supplying a different id. Add an ownership filter in the same call,
+      e.g. `.filter($MODEL.id == $ID, $MODEL.user_id == current_user.id)`.
+      (Heuristic rule — expect some false positives on genuinely
+      global/shared models.)
+    metadata:
+      owasp_category: "A01:2021 - Broken Access Control"
+      cwe: "CWE-639"
+      internal_severity: HIGH
+    patterns:
+      - pattern-either:
+          - pattern: $DB.query($MODEL).filter($MODEL.id == $ID).first()
+          - pattern: $DB.query($MODEL).filter($MODEL.id == $ID).one()
+          - pattern: $DB.query($MODEL).filter($MODEL.id == $ID).one_or_none()
+
+  # --- Privilege escalation -------------------------------------------------
+
+  - id: django-serializer-writable-role-field
+    languages: [python]
+    severity: ERROR
+    message: >-
+      This serializer's explicit `fields` list includes a privilege/tenancy
+      field (role, is_staff, is_superuser, is_admin, tenant_id,
+      organization_id, permissions) with no matching entry in
+      `read_only_fields`. Any client that can call this serializer's
+      create/update can set their own role or move themselves to another
+      tenant. Move the field to `read_only_fields`, or drop it from `fields`
+      and set it only from trusted server-side code.
+    metadata:
+      owasp_category: "A01:2021 - Broken Access Control"
+      cwe: "CWE-915"
+      internal_severity: CRITICAL
+    patterns:
+      - pattern: fields = [...]
+      - pattern-inside: |
+          class $META:
+              ...
+      - metavariable-regex:
+          metavariable: $META
+          regex: "Meta"
+      - pattern-regex: "(role|is_staff|is_superuser|is_admin|tenant_id|organization_id|permissions)"
+      - pattern-not-inside: |
+          class $META:
+              ...
+              read_only_fields = ...
+              ...
+
+  - id: django-request-data-role-assignment
+    languages: [python]
+    severity: ERROR
+    message: >-
+      A privilege/tenancy attribute is being set directly from
+      `request.data`/`request.POST`/`request.GET`. If this code path is
+      reachable by a normal (non-admin) authenticated user, they can grant
+      themselves elevated privileges or move themselves into another tenant
+      by sending that field in the request body. Set this field only from
+      trusted server-side logic, gated behind an explicit admin/role check.
+    metadata:
+      owasp_category: "A01:2021 - Broken Access Control"
+      cwe: "CWE-269"
+      internal_severity: CRITICAL
+    patterns:
+      - pattern-either:
+          - pattern: $OBJ.role = request.data[...]
+          - pattern: $OBJ.role = request.data.get(...)
+          - pattern: $OBJ.is_staff = request.data[...]
+          - pattern: $OBJ.is_staff = request.data.get(...)
+          - pattern: $OBJ.is_superuser = request.data[...]
+          - pattern: $OBJ.is_superuser = request.data.get(...)
+          - pattern: $OBJ.is_admin = request.data[...]
+          - pattern: $OBJ.is_admin = request.data.get(...)
+          - pattern: $OBJ.tenant_id = request.data[...]
+          - pattern: $OBJ.tenant_id = request.data.get(...)
+          - pattern: $OBJ.organization_id = request.data[...]
+          - pattern: $OBJ.organization_id = request.data.get(...)
+
+  # --- RBAC / function-level authorization ----------------------------------
+
+  - id: django-admin-view-missing-permission-decorator
+    languages: [python]
+    severity: WARNING
+    message: >-
+      This function-based view's own name looks admin/internal-only but the
+      function has no visible access-control decorator (e.g.
+      `@staff_member_required`, `@permission_required`, `@user_passes_test`,
+      `@login_required` combined with a role check). Being reachable isn't
+      the same as being authorized — verify the caller's role explicitly for
+      privileged views. (Heuristic rule based on the view's own name, since a
+      Django function-based view's URL path lives in urls.py rather than a
+      decorator on the function itself; adjust to your project's naming/
+      decorator conventions.)
+    metadata:
+      owasp_category: "A01:2021 - Broken Access Control"
+      cwe: "CWE-862"
+      internal_severity: MEDIUM
+    patterns:
+      - pattern: |
+          def $FUNC(request, ...):
+              ...
+      - metavariable-regex:
+          metavariable: $FUNC
+          regex: ".*(admin|internal)_.*"
+      - metavariable-regex:
+          # Separate condition (not merged into the one above): a name
+          # starting with `_` is almost always a private helper — quite
+          # often the *implementation* of the permission check itself
+          # (confirmed live: this rule initially flagged
+          # dashboard/views.py::_require_admin_org, which does exactly
+          # that) — not a URL-routed view that could be missing one. The
+          # `^` anchor excludes it under search-style matching too, not
+          # just full-string matching.
+          metavariable: $FUNC
+          regex: "^[^_]"
+      - pattern-not-regex: "(staff_member_required|permission_required|user_passes_test|is_staff|is_superuser|require_role|check_permission|can_[a-z_]*\\()"
+
+  # --- JWT / token security (P1b phase 1, PyJWT) -----------------------------
+  #
+  # Grounded in PyJWT specifically (CodeIntely's own real dependency) — not
+  # python-jose or Node's jsonwebtoken, which don't get rules until they get
+  # their own benchmark coverage. Every rule below targets jwt.decode()/
+  # jwt.encode() call sites, matched via pattern + pattern-regex on the call's
+  # own source text rather than a rigid AST shape, since PyJWT's kwargs
+  # (options=, algorithms=, audience=, issuer=) can appear in any order/
+  # combination.
+
+  - id: jwt-decode-verify-signature-disabled
+    languages: [python]
+    severity: ERROR
+    message: >-
+      This `jwt.decode()` call disables signature verification
+      (`options={"verify_signature": False}` or the legacy `verify=False`).
+      A JWT with a disabled signature check can be forged with any payload —
+      an attacker can set themselves as any user/role without knowing the
+      signing key. Remove the override; if inspecting an unverified token's
+      claims is genuinely needed (e.g. to pick a key before real
+      verification), use `jwt.get_unverified_header()`/
+      `jwt.decode(..., options={"verify_signature": False})` only on a code
+      path that never trusts the resulting claims for authn/authz.
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-347"
+      internal_severity: CRITICAL
+    patterns:
+      - pattern: jwt.decode(...)
+      - pattern-regex: "verify_signature['\"]?\\s*:\\s*False|verify\\s*=\\s*False"
+
+  - id: jwt-decode-algorithm-none-allowed
+    languages: [python]
+    severity: ERROR
+    message: >-
+      This `jwt.decode()` call's `algorithms=` allowlist includes `"none"`.
+      The "none" algorithm means the token has no signature at all — anyone
+      can craft a token with `alg: none` and any claims they like, and it
+      will pass verification. Never include "none" in the allowlist; specify
+      only the real algorithm(s) your issuer actually signs with (e.g.
+      `algorithms=["RS256"]`).
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-347"
+      internal_severity: CRITICAL
+    patterns:
+      - pattern: jwt.decode(...)
+      - pattern-regex: "(?i)algorithms\\s*=\\s*\\[[^\\]]*['\"]none['\"]"
+
+  - id: jwt-decode-missing-algorithms
+    languages: [python]
+    severity: WARNING
+    message: >-
+      This `jwt.decode()` call has no `algorithms=` allowlist. Without one,
+      PyJWT (depending on version) may trust whatever algorithm the token's
+      own header claims — including switching from an asymmetric algorithm
+      (RS256) to a symmetric one (HS256) using the public key as the HMAC
+      secret, a well-known JWT algorithm-confusion attack. Always pass an
+      explicit `algorithms=[...]` naming only the algorithm(s) your issuer
+      uses.
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-347"
+      internal_severity: HIGH
+    patterns:
+      - pattern: jwt.decode(...)
+      - pattern-not: jwt.decode(..., algorithms=$ALGOS, ...)
+      - pattern-not-regex: "verify_signature['\"]?\\s*:\\s*False|verify\\s*=\\s*False"
+
+  - id: jwt-decode-missing-audience-or-issuer-check
+    languages: [python]
+    severity: WARNING
+    message: >-
+      This `jwt.decode()` call verifies the signature (an `algorithms=`
+      allowlist is present) but passes no `audience=`/`issuer=` check. A
+      correctly-signed token issued for a *different* app or purpose by the
+      same identity provider will still pass verification here — the
+      signature alone doesn't prove the token was meant for this service.
+      Pass `audience=`/`issuer=` matching this service's own expected
+      values, or confirm this token's issuer never mints tokens for more
+      than one audience. (Heuristic rule — expect some false positives on
+      single-audience internal-only issuers.)
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-345"
+      internal_severity: MEDIUM
+    patterns:
+      - pattern: jwt.decode(..., algorithms=$ALGOS, ...)
+      - pattern-not: jwt.decode(..., audience=$AUD, ...)
+      - pattern-not: jwt.decode(..., issuer=$ISS, ...)
+
+  - id: jwt-hardcoded-signing-key
+    languages: [python]
+    severity: ERROR
+    message: >-
+      This `jwt.encode()`/`jwt.decode()` call's signing/verification key is
+      a string literal, not a value loaded from settings/environment/secret
+      storage. A key committed to source control is exposed to anyone with
+      repo access (including through git history, even if later removed)
+      and can't be rotated without a code change. Load it from
+      `settings.*`/an environment variable/a secret manager instead.
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-321"
+      internal_severity: HIGH
+    patterns:
+      - pattern-either:
+          - pattern: jwt.encode($PAYLOAD, "...", ...)
+          - pattern: jwt.encode($PAYLOAD, key="...", ...)
+          - pattern: jwt.decode($TOKEN, "...", ...)
+          - pattern: jwt.decode($TOKEN, key="...", ...)
+
+  # --- OAuth/OIDC (P1b phase 2) ----------------------------------------------
+  #
+  # githubapp/oauth_views.py is this codebase's own real, correct OAuth
+  # flow (generates+stores `state` at authorize time, validates it at
+  # callback) — used as the template for what "safe" looks like. ID-token
+  # audience/issuer validation is NOT a new rule here — it reuses
+  # jwt-decode-missing-audience-or-issuer-check from phase 1 directly,
+  # since an OIDC ID token is just a JWT.
+  #
+  # Design note, found the hard way by running these rules against the
+  # real oauth_views.py (not just synthetic fixtures): a `pattern:` whose
+  # primary/base match is a whole function body via bare `def $FUNC(...):
+  # ...` — combined with `pattern-regex`/`pattern-not-regex` checks meant
+  # to scan "the whole function" — is unreliable. Semgrep can enumerate
+  # multiple overlapping candidate spans for how far a body `...` extends,
+  # and a regex is checked independently against each candidate; a
+  # candidate that happens to end *before* the line that would have
+  # satisfied/excluded the check produces a spurious match even though the
+  # complete function does not. Confirmed live: an earlier version of the
+  # two rules below flagged this codebase's own real, correct
+  # github_login()/github_callback() over a dozen times each, despite both
+  # correctly generating/storing/validating state. Fixed by anchoring the
+  # base `pattern:` on one exact statement (a dict literal, an
+  # assignment) — a single AST node, not an open-ended statement sequence
+  # — and using `pattern-inside`/`pattern-not-inside`/`pattern-not` for
+  # everything else, all of which are structural (AST-shape) containment
+  # checks rather than regex-over-a-range, so this class of bug can't
+  # recur here. Re-verified against oauth_views.py directly: zero findings.
+
+  - id: oauth-authorize-redirect-missing-state
+    languages: [python]
+    severity: ERROR
+    message: >-
+      This OAuth/OIDC authorize params dict includes `client_id` (the
+      shape of a provider-authorize request) but no `state` key. Without a
+      per-request, server-stored `state` value round-tripped through the
+      provider and checked at callback, the flow is vulnerable to CSRF —
+      an attacker can trick a victim into completing *the attacker's*
+      OAuth flow, linking the victim's session to an account the attacker
+      controls. Generate a random `state` (`secrets.token_urlsafe(...)`),
+      store it (session), include it in the authorize redirect, and
+      validate it at the callback. (Heuristic rule — only recognizes
+      `state` declared inline in this dict literal, not one added via a
+      later `params["state"] = ...` assignment.)
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-352"
+      internal_severity: HIGH
+    patterns:
+      - pattern: '$PARAMS = {"client_id": ..., ...}'
+      - pattern-not: '$PARAMS = {..., "state": ..., ...}'
+      - pattern-inside: |
+          def $FUNC(request):
+              ...
+      - metavariable-regex:
+          metavariable: $FUNC
+          regex: "(?i).*(login|authorize|oauth).*"
+
+  - id: oauth-callback-state-not-validated
+    languages: [python]
+    severity: ERROR
+    message: >-
+      This OAuth/OIDC callback view reads `state` from the request but
+      this function contains no comparison of it against another value —
+      receiving a `state` param isn't the same as validating it came back
+      unchanged. Compare the callback's `state` against the value stashed
+      in the session at authorize time (e.g. `if state != expected_state:
+      reject`), and reject the callback if they don't match (see
+      `github_callback()` in this same codebase for a real, correct
+      reference implementation).
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-352"
+      internal_severity: HIGH
+    patterns:
+      - pattern: $STATE = request.GET.get("state")
+      - pattern-inside: |
+          def $FUNC(request):
+              ...
+      - metavariable-regex:
+          metavariable: $FUNC
+          regex: "(?i).*callback.*"
+      - pattern-not-inside: |
+          def $FUNC(request):
+              ...
+              if <... $STATE != $EXPECTED ...>:
+                  ...
+      - pattern-not-inside: |
+          def $FUNC(request):
+              ...
+              if <... $EXPECTED != $STATE ...>:
+                  ...
+      - pattern-not-inside: |
+          def $FUNC(request):
+              ...
+              if <... $STATE == $EXPECTED ...>:
+                  ...
+      - pattern-not-inside: |
+          def $FUNC(request):
+              ...
+              if <... $EXPECTED == $STATE ...>:
+                  ...
+
+  - id: oauth-redirect-uri-from-request-input
+    languages: [python]
+    severity: ERROR
+    message: >-
+      `redirect_uri` is being sourced directly from request input rather
+      than a fixed, server-side value. If the OAuth provider doesn't
+      strictly validate `redirect_uri` against an exact registered allowlist
+      (many only check a prefix/domain), an attacker can redirect the
+      authorization code or access token to a host they control. Use a
+      fixed `redirect_uri` (a constant or `settings.*` value), never one
+      built from `request.GET`/`request.POST`/`request.data`.
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-601"
+      internal_severity: HIGH
+    patterns:
+      - pattern-either:
+          - pattern: redirect_uri = request.GET.get(...)
+          - pattern: redirect_uri = request.GET[...]
+          - pattern: redirect_uri = request.POST.get(...)
+          - pattern: redirect_uri = request.POST[...]
+          - pattern: redirect_uri = request.data.get(...)
+          - pattern: redirect_uri = request.data[...]
+          - pattern: redirect_uri = request.args.get(...)
+
+  - id: oauth-authorize-missing-pkce
+    languages: [python]
+    severity: WARNING
+    message: >-
+      This view's own name signals a public-client OAuth/OIDC flow (mobile/
+      SPA/native), but it has no `code_challenge` (PKCE) in its authorize
+      redirect. Public clients have no confidential secret to authenticate
+      the token exchange with, which is exactly the case PKCE exists to
+      protect: without it, an intercepted authorization code can be
+      redeemed by whoever captured it. Add PKCE (`code_challenge`/
+      `code_challenge_method` at authorize time, `code_verifier` at token
+      exchange). Deliberately name-scoped rather than checking for an
+      absent `client_secret` in this same function — a confidential
+      client's token exchange commonly lives in a separate callback
+      function (this codebase's own `github_login()`/`github_callback()`
+      split is a real example), so "no client_secret in this function" is
+      not, by itself, a reliable public-vs-confidential signal. (Heuristic
+      rule — only fires on views whose own name says public client; expect
+      false negatives on public clients that don't name themselves this
+      way, not false positives on confidential ones.)
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-287"
+      internal_severity: MEDIUM
+    patterns:
+      - pattern: '$PARAMS = {"client_id": ..., ...}'
+      - pattern-not: '$PARAMS = {..., "code_challenge": ..., ...}'
+      - pattern-inside: |
+          def $FUNC(request):
+              ...
+      - metavariable-regex:
+          metavariable: $FUNC
+          regex: "(?i).*(mobile|spa|native|public_client|pkce).*"
+
+  # --- Session security (P1b phase 3) ----------------------------------------
+  #
+  # The three cookie-flag rules are deliberately single-line settings
+  # matches, same style/reliability as the existing django-debug-true rule
+  # — no ellipsis/regex-scoping risk at all. The two code-pattern rules
+  # reuse structural idioms already proven reliable this phase: a
+  # well-anchored base statement (never bare `def $FUNC(...): ...` alone)
+  # plus `pattern-inside`/`pattern-not`/`pattern-not-inside` for
+  # containment, verified against this codebase's own real
+  # github_login()/github_callback()/github_logout() (oauth_views.py) —
+  # which correctly uses login()/logout() and is not flagged.
+
+  - id: django-session-cookie-not-secure
+    languages: [python]
+    severity: ERROR
+    message: >-
+      SESSION_COOKIE_SECURE = False means the session cookie is sent over
+      plain HTTP too, not just HTTPS — on any mixed-content page, cached
+      redirect, or network position between the user and the server, the
+      session cookie can be captured in the clear and replayed. Set
+      SESSION_COOKIE_SECURE = True (and terminate the site on HTTPS only).
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-614"
+      internal_severity: HIGH
+    pattern: SESSION_COOKIE_SECURE = False
+
+  - id: django-session-cookie-not-httponly
+    languages: [python]
+    severity: ERROR
+    message: >-
+      SESSION_COOKIE_HTTPONLY = False makes the session cookie readable
+      from JavaScript (`document.cookie`) — any XSS on the site can steal
+      the session cookie directly, not just data visible in the DOM. Set
+      SESSION_COOKIE_HTTPONLY = True (Django's own default — this is an
+      explicit opt-out of it).
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-1004"
+      internal_severity: HIGH
+    pattern: SESSION_COOKIE_HTTPONLY = False
+
+  - id: django-session-cookie-samesite-weak
+    languages: [python]
+    severity: WARNING
+    message: >-
+      SESSION_COOKIE_SAMESITE is set to a value that drops or weakens the
+      SameSite cookie attribute (False/None/"None") — the session cookie
+      is then sent on cross-site requests too, removing a real layer of
+      CSRF defense-in-depth. Use "Lax" (Django's own default) unless this
+      app genuinely needs the session cookie sent cross-site (e.g. an
+      embedded iframe use case), in which case "None" requires
+      SESSION_COOKIE_SECURE = True as well.
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-352"
+      internal_severity: MEDIUM
+    patterns:
+      - pattern-either:
+          - pattern: SESSION_COOKIE_SAMESITE = False
+          - pattern: SESSION_COOKIE_SAMESITE = None
+          - pattern: SESSION_COOKIE_SAMESITE = "None"
+
+  - id: django-custom-session-write-missing-rotation
+    languages: [python]
+    severity: ERROR
+    message: >-
+      This view writes an authentication-shaped key directly into
+      `request.session` (marking someone as logged in) without calling
+      Django's `login()` (which auto-rotates the session key) or
+      `request.session.cycle_key()` anywhere in the same function. Reusing
+      the pre-login session key after authenticating is session fixation —
+      an attacker who fixed a victim's session id before login (e.g. via a
+      shared/public terminal, or a session id planted through another
+      vulnerability) inherits the now-authenticated session. Use Django's
+      `login(request, user)` for standard auth, or call
+      `request.session.cycle_key()` explicitly right after establishing
+      the authenticated identity in a custom flow.
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-384"
+      internal_severity: HIGH
+    patterns:
+      - pattern: request.session[$KEY] = $VAL
+      - metavariable-regex:
+          metavariable: $KEY
+          regex: '(?i).*(user_id|authenticated|logged_in|is_logged_in|\buid\b).*'
+      - pattern-inside: |
+          def $FUNC(request):
+              ...
+      - pattern-not-inside: |
+          def $FUNC(request):
+              ...
+              login(request, ...)
+              ...
+      - pattern-not-inside: |
+          def $FUNC(request):
+              ...
+              $S.cycle_key()
+              ...
+
+  - id: django-logout-view-missing-logout-call
+    languages: [python]
+    severity: WARNING
+    message: >-
+      This view's own name signals a logout action, but its body never
+      calls Django's `logout()`. Manually clearing one session key (or
+      just returning a "logged out" response) without `logout()` leaves
+      the rest of the session data and the session's own auth backend
+      state intact server-side — the session may still be valid if the
+      client re-sends the same session cookie. Call Django's
+      `logout(request)`, which flushes the session properly.
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-613"
+      internal_severity: MEDIUM
+    patterns:
+      - pattern: |
+          def $FUNC(request):
+              ...
+      - metavariable-regex:
+          metavariable: $FUNC
+          regex: "(?i).*logout.*"
+      - pattern-not: |
+          def $FUNC(request):
+              ...
+              logout(...)
+              ...
+
+  # --- Authentication, general (P1b phase 4) ---------------------------------
+  #
+  # Scoped narrowly, per the plan: plaintext password storage, missing
+  # rate-limiting on auth endpoints, weak password-reset token generation.
+  # Account enumeration (differing error messages) deliberately NOT built
+  # — flagged in planning as a likely-noisy candidate, not worth forcing
+  # in without evidence it earns its keep. This codebase has no local
+  # password auth of its own (GitHub OAuth only) to benchmark against
+  # directly, so these fixtures model well-known Django idioms rather
+  # than mirroring a real internal reference implementation.
+
+  - id: django-plaintext-password-assignment
+    languages: [python]
+    severity: ERROR
+    message: >-
+      A password is being written directly to the `password` field —
+      either via `Model.objects.create(password=...)` or a direct
+      `user.password = ...` assignment — bypassing Django's hashing
+      entirely. Unlike `create_user()`/`set_password()`, this stores the
+      raw value as-is; if it's ever a plaintext password (not an
+      already-hashed one from `make_password()`), any database read (a
+      backup, a breach, an internal tool) exposes every affected user's
+      real password. Use `User.objects.create_user(...)` or call
+      `user.set_password(raw_password)` before saving.
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-256"
+      internal_severity: CRITICAL
+    patterns:
+      - pattern-either:
+          - pattern: $MODEL.objects.create(..., password=$P, ...)
+          - pattern: $USER.password = $P
+      - pattern-not: $MODEL.objects.create(..., password=make_password(...), ...)
+      - pattern-not: $USER.password = make_password(...)
+
+  - id: django-auth-view-missing-rate-limit
+    languages: [python]
+    severity: WARNING
+    message: >-
+      This login/password-reset view's own name suggests an
+      authentication entry point, but it has no visible rate-limiting
+      decorator (`@ratelimit`, a DRF throttle class, or similar). This
+      flags the code-level *absence of a rate-limiting mechanism* near the
+      view — not "this endpoint is being brute-forced," which is a
+      runtime signal out of scope for a static scanner. Without any
+      throttle, credential-stuffing and password-guessing attempts against
+      this endpoint are limited only by network conditions. Add
+      `django-ratelimit`'s `@ratelimit(...)`, a DRF `throttle_classes`, or
+      equivalent. (Heuristic rule based on the view's own name and nearby
+      decorators — expect some false positives where rate-limiting is
+      enforced elsewhere, e.g. at a reverse proxy/WAF/API gateway.)
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-307"
+      internal_severity: MEDIUM
+    patterns:
+      - pattern: |
+          def $FUNC(request, ...):
+              ...
+      - metavariable-regex:
+          metavariable: $FUNC
+          regex: "(?i).*(login|signin|sign_in|password_reset|reset_password|forgot_password).*"
+      - metavariable-regex:
+          # Same reasoning as django-admin-view-missing-permission-decorator's
+          # identical guard: a name starting with `_` is a private helper,
+          # not a URL-routed view.
+          metavariable: $FUNC
+          regex: "^[^_]"
+      - pattern-not-regex: "(?i)(ratelimit|throttle)"
+
+  - id: django-weak-password-reset-token
+    languages: [python]
+    severity: ERROR
+    message: >-
+      This password-reset/verification token is generated with `random`
+      (not cryptographically secure — seeded, predictable, and
+      reproducible by anyone who can infer or brute-force the internal
+      state) or a truncated `uuid4()` (deliberately shortening an
+      already-random value throws away entropy, making it more
+      guessable). A guessable reset token lets an attacker take over any
+      account whose email/reset flow they can trigger. Use Django's
+      `PasswordResetTokenGenerator` or `secrets.token_urlsafe(...)`
+      (cryptographically secure, full entropy, not truncated).
+    metadata:
+      owasp_category: "A07:2021 - Identification and Authentication Failures"
+      cwe: "CWE-330"
+      internal_severity: HIGH
+    patterns:
+      - pattern-either:
+          - pattern: $TOKEN = random.randint(...)
+          - pattern: $TOKEN = random.choice(...)
+          - pattern: $TOKEN = random.random()
+          - pattern: $TOKEN = str(uuid.uuid4())[:$N]
+      - metavariable-regex:
+          metavariable: $TOKEN
+          regex: "(?i).*(reset_token|password_token|reset_code|verification_token|reset_key).*"