strix-agent 0.1.18__py3-none-any.whl → 0.3.1__py3-none-any.whl

strix/prompts/technologies/firebase_firestore.jinja

@@ -0,0 +1,177 @@
+<firebase_firestore_security_guide>
+<title>FIREBASE / FIRESTORE — ADVERSARIAL TESTING AND EXPLOITATION</title>
+
+<critical>Most impactful findings in Firebase apps arise from weak Firestore/Realtime Database rules, Cloud Storage exposure, callable/onRequest Functions trusting client input, incorrect ID token validation, and over-trusted App Check. Treat every client-supplied field and token as untrusted. Bind subject/tenant on the server, not in the client.</critical>
+
+<scope>
+- Firestore (documents/collections, rules, REST/SDK)
+- Realtime Database (JSON tree, rules)
+- Cloud Storage (rules, signed URLs)
+- Auth (ID tokens, custom claims, anonymous/sign-in providers)
+- Cloud Functions (onCall/onRequest, triggers)
+- Hosting rewrites, CDN/caching, CORS
+- App Check (attestation) and its limits
+</scope>
+
+<methodology>
+1. Extract project config from client (apiKey, authDomain, projectId, appId, storageBucket, messagingSenderId). Identify all used Firebase products.
+2. Obtain multiple principals: unauth, anonymous (if enabled), basic user A, user B, and any staff/admin if available. Capture their ID tokens.
+3. Build Resource × Action × Principal matrix across Firestore/Realtime/Storage/Functions. Exercise every action via SDK and raw REST (googleapis) to detect parity gaps.
+4. Start from list/query paths (where allowed) to seed IDs; then swap document paths, tenants, and user IDs across principals and transports.
+</methodology>
+
+<architecture>
+- Firestore REST: https://firestore.googleapis.com/v1/projects/<project>/databases/(default)/documents/<path>
+- Storage REST: https://storage.googleapis.com/storage/v1/b/<bucket>
+- Auth: Google-signed ID tokens (iss accounts.google.com/securetoken.google.com/<project>), aud <project/app-id>; identity is in sub/uid.
+- Rules engines: separate for Firestore, Realtime DB, and Storage; Functions bypass rules when using Admin SDK.
+</architecture>
+
+<auth_and_tokens>
+- ID token verification must enforce issuer, audience (project), signature (Google JWKS), expiration, and optionally App Check binding when used.
+- Custom claims are appended by Admin SDK; client-supplied claims are ignored by Auth but may be trusted by app code if copied into docs.
+- Pitfalls:
+  - Accepting any JWT with valid signature but wrong audience/project.
+  - Trusting uid/account IDs from request body instead of context.auth.uid in Functions.
+  - Mixing session cookies and ID tokens without verifying both paths equivalently.
+- Tests:
+  - Replay tokens across environments/projects; expect strict aud/iss rejection server-side.
+  - Call Functions with and without Authorization; verify identical checks on both onCall and onRequest variants.
+</auth_and_tokens>
+
+<firestore_rules>
+- Rules are not filters: a query must include constraints that make the rule true for all returned documents; otherwise reads fail. Do not rely on client to include where clauses correctly.
+- Prefer ownership derived from request.auth.uid and server data, not from client payload fields.
+- Common gaps:
+  - allow read: if request.auth != null (any user reads all data)
+  - allow write: if request.auth != null (mass write)
+  - Missing per-field validation (adds isAdmin/role/tenantId fields).
+  - Using client-supplied ownerId/orgId instead of enforcing doc.ownerId == request.auth.uid or membership in org.
+  - Over-broad list rules on root collections; per-doc checks exist but list still leaks via queries.
+- Validation patterns:
+  - Restrict writes: request.resource.data.keys().hasOnly([...]) and forbid privilege fields.
+  - Enforce ownership: resource.data.ownerId == request.auth.uid && request.resource.data.ownerId == request.auth.uid
+  - Org membership: exists(/databases/(default)/documents/orgs/$(org)/members/$(request.auth.uid))
+- Tests:
+  - Compare results for users A/B on identical queries; diff counts and IDs.
+  - Attempt cross-tenant reads: where orgId == otherOrg; try queries without org filter to confirm denial.
+  - Write-path: set/patch with foreign ownerId/orgId; attempt to flip privilege flags.
+</firestore_rules>
+
+<firestore_queries>
+- Enumerate via REST to avoid SDK client-side constraints; try structured and REST filters.
+- Probe composite index requirements: UI-driven queries may hide missing rule coverage when indexes are enabled but rules are broad.
+- Explore collection group queries (collectionGroup) that may bypass per-collection rules if not mirrored.
+- Use startAt/endAt/in/array-contains to probe rule edges and pagination cursors for cross-tenant bleed.
+</firestore_queries>
+
+<realtime_database>
+- Misconfigured rules frequently expose entire JSON trees. Probe https://<project>.firebaseio.com/.json with and without auth.
+- Confirm rules for read/write use auth.uid and granular path checks; avoid .read/.write: true or auth != null at high-level nodes.
+- Attempt to write privilege-bearing nodes (roles, org membership) and observe downstream effects (e.g., Cloud Functions triggers).
+</realtime_database>
+
+<cloud_storage>
+- Rules parallel Firestore but apply to object paths. Common issues:
+  - Public reads on sensitive buckets/paths.
+  - Signed URLs with long TTL, no content-disposition controls; replayable across tenants.
+  - List operations exposed: /o?prefix= enumerates object keys.
+- Tests:
+  - GET gs:// paths via https endpoints without auth; verify content-type and Content-Disposition: attachment.
+  - Generate and reuse signed URLs across accounts and paths; try case/URL-encoding variants.
+  - Upload HTML/SVG and verify X-Content-Type-Options: nosniff; check for script execution.
+</cloud_storage>
+
+<cloud_functions>
+- onCall provides context.auth automatically; onRequest must verify ID tokens explicitly. Admin SDK bypasses rules; all ownership/tenant checks must be enforced in code.
+- Common gaps:
+  - Trusting client uid/orgId from request body instead of context.auth.
+  - Missing aud/iss verification when manually parsing tokens.
+  - Over-broad CORS allowing credentialed cross-origin requests; echoing Authorization in responses.
+  - Triggers (onCreate/onWrite) granting roles or issuing signed URLs solely based on document content controlled by the client.
+- Tests:
+  - Call both onCall and equivalent onRequest endpoints with varied tokens and bodies; expect identical decisions.
+  - Create crafted docs to trigger privilege-granting functions; verify that server re-derives subject/tenant before acting.
+  - Attempt internal fetches (SSRF) via Functions to project/metadata endpoints.
+</cloud_functions>
+
+<app_check>
+- App Check is not a substitute for authorization. Many apps enable App Check enforcement on client SDKs but do not verify on custom backends.
+- Bypasses:
+  - Unenforced paths: REST calls directly to googleapis endpoints with ID token succeed regardless of App Check.
+  - Mobile reverse engineering: hook client and reuse ID token flows without attestation.
+- Tests:
+  - Compare SDK vs REST behavior with/without App Check headers; confirm no elevated authorization via App Check alone.
+</app_check>
+
+<tenant_isolation>
+- Apps often implement multi-tenant data models (orgs/<orgId>/...). Bind tenant from server context (membership doc or custom claim), not from client payload.
+- Tests:
+  - Vary org header/subdomain/query while keeping token fixed; verify server denies cross-tenant access.
+  - Export/report Functions: ensure queries execute under caller scope; signed outputs must encode tenant and short TTL.
+</tenant_isolation>
+
+<bypass_techniques>
+- Content-type switching: JSON vs form vs multipart to hit alternate code paths in onRequest Functions.
+- Parameter/field pollution: duplicate JSON keys; last-one-wins in many parsers; attempt to sneak privilege fields.
+- Caching/CDN: Hosting rewrites or proxies that key responses without Authorization or tenant headers.
+- Race windows: write then read before background enforcements (e.g., post-write claim synchronizations) complete.
+</bypass_techniques>
+
+<blind_channels>
+- Firestore: use error shape, document count, and ETag/length to infer existence under partial denial.
+- Storage: length/timing differences on signed URL attempts leak validity.
+- Functions: constant-time comparisons vs variable messages reveal authorization branches.
+</blind_channels>
+
+<tooling_and_automation>
+- SDK + REST: httpie/curl + jq for REST; Firebase emulator and Rules Playground for rapid iteration.
+- Mobile: apktool/objection/frida to extract config and hook SDK calls; inspect network logs for endpoints and tokens.
+- Rules analysis: script rule probes for common patterns (auth != null, missing field validation, list vs get parity).
+- Functions: fuzz onRequest endpoints with varied content-types and missing/forged Authorization; verify CORS and token handling.
+- Storage: enumerate prefixes; test signed URL generation and reuse patterns.
+</tooling_and_automation>
+
+<reviewer_checklist>
+- Do Firestore/Realtime/Storage rules derive subject and tenant from auth, not client fields?
+- Are list/query rules aligned with per-doc checks (no broad list leaks)?
+- Are privilege-bearing fields immutable or server-only (forbidden in writes)?
+- Do Functions verify ID tokens (iss/aud/exp/signature) and re-derive identity before acting?
+- Are Admin SDK operations scoped by server-side checks (ownership/tenant)?
+- Is App Check treated as advisory, not authorization, across all paths?
+- Are Hosting/CDN cache keys bound to Authorization/tenant to prevent leaks?
+</reviewer_checklist>
+
+<validation>
+1. Provide owner vs non-owner Firestore queries showing unauthorized access or metadata leak.
+2. Demonstrate Cloud Storage read/write beyond intended scope (public object, signed URL reuse, or list exposure).
+3. Show a Function accepting forged/foreign identity (wrong aud/iss) or trusting client uid/orgId.
+4. Document minimal reproducible requests with roles/tokens used and observed deltas.
+</validation>
+
+<false_positives>
+- Public collections/objects documented and intended.
+- Rules that correctly enforce per-doc checks with matching query constraints.
+- Functions verifying tokens and ignoring client-supplied identifiers.
+- App Check enforced but not relied upon for authorization.
+</false_positives>
+
+<impact>
+- Cross-account and cross-tenant data exposure.
+- Unauthorized state changes via Functions or direct writes.
+- Exfiltration of PII/PHI and private files from Storage.
+- Durable privilege escalation via misused custom claims or triggers.
+</impact>
+
+<pro_tips>
+1. Treat apiKey as project identifier only; identity must come from verified ID tokens.
+2. Start from rules: read them, then prove gaps with diffed owner/non-owner requests.
+3. Prefer REST for parity checks; SDKs can mask errors via client-side filters.
+4. Hunt privilege fields in docs and forbid them via rules; verify immutability.
+5. Probe collectionGroup queries and list rules; many leaks live there.
+6. Functions are the authority boundary—enforce subject/tenant there even if rules exist.
+7. Keep concise PoCs: one owner vs non-owner request per surface that clearly demonstrates the unauthorized delta.
+</pro_tips>
+
+<remember>Authorization must hold at every layer: rules, Functions, and Storage. Bind subject and tenant from verified tokens and server data, never from client payload or UI assumptions. Any gap becomes a cross-account or cross-tenant vulnerability.</remember>
+</firebase_firestore_security_guide>

strix/prompts/technologies/supabase.jinja

@@ -0,0 +1,189 @@
+<supabase_security_guide>
+<title>SUPABASE — ADVERSARIAL TESTING AND EXPLOITATION</title>
+
+<critical>Supabase exposes Postgres through PostgREST, Realtime, GraphQL, Storage, Auth (GoTrue), and Edge Functions. Most impactful findings come from mis-scoped Row Level Security (RLS), unsafe RPCs, leaked service_role keys, lax Storage policies, GraphQL overfetching, and Edge Functions trusting headers or tokens without binding to issuer/audience/tenant.</critical>
+
+<scope>
+- PostgREST: table CRUD, filters, embeddings, RPC (remote functions)
+- RLS: row ownership/tenant isolation via policies and auth.uid()
+- Storage: buckets, objects, signed URLs, public/private policies
+- Realtime: replication subscriptions, broadcast/presence channels
+- GraphQL: pg_graphql over Postgres schema with RLS interaction
+- Auth (GoTrue): JWTs, cookie/session, magic links, OAuth flows
+- Edge Functions (Deno): server-side code calling Supabase with secrets
+</scope>
+
+<methodology>
+1. Inventory surfaces: REST /rest/v1, Storage /storage/v1, GraphQL /graphql/v1, Realtime wss, Auth /auth/v1, Functions https://<project>.functions.supabase.co/.
+2. Obtain tokens for: unauth (anon), basic user, other user, and (if disclosed) admin/staff; enumerate anon key exposure and verify if service_role leaked anywhere.
+3. Build a Resource × Action × Principal matrix and test each via REST and GraphQL. Confirm parity across channels and content-types (json/form/multipart).
+4. Start with list/search/export endpoints to gather IDs, then attempt direct reads/writes across principals, tenants, and transports. Validate RLS and function guards.
+</methodology>
+
+<architecture>
+- Project endpoints: https://<ref>.supabase.co; REST at /rest/v1/<table>, RPC at /rest/v1/rpc/<fn>.
+- Headers: apikey: <anon-or-service>, Authorization: Bearer <JWT>. Anon key only identifies the project; JWT binds user context.
+- Roles: anon, authenticated; service_role bypasses RLS and must never be client-exposed.
+- auth.uid(): current user UUID claim; policies must never trust client-supplied IDs over server context.
+</architecture>
+
+<rls>
+- Enable RLS on every non-public table; absence or “permit-all” policies → bulk exposure.
+- Common gaps:
+  - Policies check auth.uid() for read but forget UPDATE/DELETE/INSERT.
+  - Missing tenant constraints (org_id/tenant_id) allow cross-tenant reads/writes.
+  - Policies rely on client-provided columns (user_id in payload) instead of deriving from JWT.
+  - Complex joins where the effective policy is applied after filters, enabling inference via counts or projections.
+- Tests:
+  - Compare results for two users: GET /rest/v1/<table>?select=*&Prefer=count=exact; diff row counts and IDs.
+  - Try cross-tenant: add &org_id=eq.<other_org> or use or=(org_id.eq.other,org_id.is.null).
+  - Write-path: PATCH/DELETE single row with foreign id; INSERT with foreign owner_id then read.
+</rls>
+
+<postgrest_and_rest>
+- Filters: eq, neq, lt, gt, ilike, or, is, in; embed relations with select=*,profile(*); exploit embeddings to overfetch linked rows if resolvers skip per-row checks.
+- Headers to know: Prefer: return=representation (echo writes), Prefer: count=exact (exposure via counts), Accept-Profile/Content-Profile to select schema.
+- IDOR patterns: /rest/v1/<table>?select=*&id=eq.<other_id>; query alternative keys (slug, email) and composite keys.
+- Search leaks: generous LIKE/ILIKE filters + lack of RLS → mass disclosure.
+- Mass assignment: if RPC not used, PATCH can update unintended columns; verify restricted columns via database permissions/policies.
+</postgrest_and_rest>
+
+<rpc_functions>
+- RPC endpoints map to SQL functions. SECURITY DEFINER bypasses RLS unless carefully coded; SECURITY INVOKER respects caller.
+- Anti-patterns:
+  - SECURITY DEFINER + missing owner checks → vertical/horizontal bypass.
+  - set search_path left to public; function resolves unsafe objects.
+  - Trusting client-supplied user_id/tenant_id rather than auth.uid().
+- Tests:
+  - Call /rest/v1/rpc/<fn> as different users with foreign ids in body.
+  - Remove or alter JWT entirely (Authorization: Bearer <anon>) to see if function still executes.
+  - Validate that functions perform explicit ownership/tenant checks inside SQL, not only in docs.
+</rpc_functions>
+
+<storage>
+- Buckets: public vs private; objects live in storage.objects with RLS-like policies.
+- Find misconfigs:
+  - Public buckets holding sensitive data: GET https://<ref>.supabase.co/storage/v1/object/public/<bucket>/<path>
+  - Signed URLs with long TTL and no audience binding; reuse/guess tokens across tenants/paths.
+  - Listing prefixes without auth: /storage/v1/object/list/<bucket>?prefix=
+  - Path confusion: mixed case, URL-encoding, “..” segments rejected at UI but accepted by API.
+- Abuse vectors:
+  - Content-type/XSS: upload HTML/SVG served as text/html or image/svg+xml; confirm X-Content-Type-Options: nosniff and Content-Disposition: attachment.
+  - Signed URL replay across accounts/buckets if validation is lax.
+</storage>
+
+<realtime>
+- Endpoint: wss://<ref>.supabase.co/realtime/v1. Join channels with apikey + Authorization.
+- Risks:
+  - Channel names derived from table/schema/filters leaking other users’ updates when RLS or channel guards are weak.
+  - Broadcast/presence channels allowing cross-room join/publish without auth checks.
+- Tests:
+  - Subscribe to public:realtime changes on protected tables; confirm row data visibility aligns with RLS.
+  - Attempt joining other users’ presence/broadcast channels (e.g., room:<user_id>, org:<id>).
+</realtime>
+
+<graphql>
+- Endpoint: /graphql/v1 using pg_graphql with RLS. Risks:
+  - Introspection reveals schema relations; ensure it’s intentional.
+  - Overfetch via nested relations where field resolvers fail to re-check ownership/tenant.
+  - Global node IDs (if implemented) leaked and reusable via different viewers.
+- Tests:
+  - Compare REST vs GraphQL responses for the same principal and query shape.
+  - Query deep nested fields and connections; verify RLS holds at each edge.
+</graphql>
+
+<auth_and_tokens>
+- GoTrue issues JWTs with claims (sub=uid, role, aud=authenticated). Validate on server: issuer, audience, exp, signature, and tenant context.
+- Pitfalls:
+  - Storing tokens in localStorage → XSS exfiltration; refresh mismanagement leading to long-lived sessions.
+  - Treating apikey as identity; it is project-scoped, not user identity.
+  - Exposing service_role key in client bundle or Edge Function responses.
+- Tests:
+  - Replay tokens across services; check audience/issuer pinning.
+  - Try downgraded tokens (expired/other audience) against custom endpoints.
+</auth_and_tokens>
+
+<edge_functions>
+- Deno-based functions often initialize server-side Supabase client with service_role. Risks:
+  - Trusting Authorization/apikey headers without verifying JWT against issuer/audience.
+  - CORS: wildcard origins with credentials; reflected Authorization in responses.
+  - SSRF via fetch; secrets exposed via error traces or logs.
+- Tests:
+  - Call functions with and without Authorization; compare behavior.
+  - Try foreign resource IDs in function payloads; verify server re-derives user/tenant from JWT.
+  - Attempt to reach internal endpoints (metadata services, project endpoints) via function fetch.
+</edge_functions>
+
+<tenant_isolation>
+- Ensure every query joins or filters by tenant_id/org_id derived from JWT context, not client input.
+- Tests:
+  - Change subdomain/header/path tenant selectors while keeping JWT tenant constant; look for cross-tenant data.
+  - Export/report endpoints: confirm queries execute under caller scope; signed outputs must encode tenant and short TTL.
+</tenant_isolation>
+
+<bypass_techniques>
+- Content-type switching: application/json ↔ application/x-www-form-urlencoded ↔ multipart/form-data to hit different code paths.
+- Parameter pollution: duplicate keys in JSON/query; PostgREST chooses last/first depending on parser.
+- GraphQL+REST parity probing: protections often drift; fetch via the weaker path.
+- Race windows: parallel writes to bypass post-insert ownership updates.
+</bypass_techniques>
+
+<blind_channels>
+- Use Prefer: count=exact and ETag/length diffs to infer unauthorized rows.
+- Conditional requests (If-None-Match) to detect object existence without content exposure.
+- Storage signed URLs: timing/length deltas to map valid vs invalid tokens.
+</blind_channels>
+
+<tooling_and_automation>
+- PostgREST: httpie/curl + jq; enumerate tables with known names; fuzz filters (or=, ilike, neq, is.null).
+- GraphQL: graphql-inspector, voyager; build deep queries to test field-level enforcement; complexity/batching tests.
+- Realtime: custom ws client; subscribe to suspicious channels/tables; diff payloads per principal.
+- Storage: enumerate bucket listing APIs; script signed URL generation/use patterns.
+- Auth/JWT: jwt-cli/jose to validate audience/issuer; replay against Edge Functions.
+- Policy diffing: maintain request sets per role and compare results across releases.
+</tooling_and_automation>
+
+<reviewer_checklist>
+- Are all non-public tables RLS-enabled with explicit SELECT/INSERT/UPDATE/DELETE policies?
+- Do policies derive subject/tenant from JWT (auth.uid(), tenant claim) rather than client payload?
+- Do RPC functions run as SECURITY INVOKER, or if DEFINER, do they enforce ownership/tenant inside?
+- Are Storage buckets private by default, with short-lived signed URLs bound to tenant/context?
+- Does Realtime enforce RLS-equivalent filtering for subscriptions and block cross-room joins?
+- Is GraphQL parity verified with REST; are nested resolvers guarded per field?
+- Are Edge Functions verifying JWT (issuer/audience) and never exposing service_role to clients?
+- Are CDN/cache keys bound to Authorization/tenant to prevent cache leaks?
+</reviewer_checklist>
+
+<validation>
+1. Provide owner vs non-owner requests for REST/GraphQL showing unauthorized access (content or metadata).
+2. Demonstrate a mis-scoped RPC or Storage signed URL usable by another user/tenant.
+3. Confirm Realtime or GraphQL exposure matches missing policy checks.
+4. Document minimal reproducible requests and role contexts used.
+</validation>
+
+<false_positives>
+- Tables intentionally public (documented) with non-sensitive content.
+- RLS-enabled tables returning only caller-owned rows; mismatched UI not backed by API responses.
+- Signed URLs with very short TTL and audience binding.
+- Edge Functions verifying tokens and re-deriving context before acting.
+</false_positives>
+
+<impact>
+- Cross-account/tenant data exposure and unauthorized state changes.
+- Exfiltration of PII/PHI/PCI, financial and billing artifacts, private files.
+- Privilege escalation via RPC and Edge Functions; durable access via long-lived tokens.
+- Regulatory and contractual violations stemming from tenant isolation failures.
+</impact>
+
+<pro_tips>
+1. Start with /rest/v1 list/search; counts and embeddings reveal policy drift fast.
+2. Treat UUIDs and signed URLs as untrusted; validate binding to subject/tenant and TTL.
+3. Focus on RPC and Edge Functions—they often centralize business logic and skip RLS.
+4. Test GraphQL and Realtime parity with REST; differences are where vulnerabilities hide.
+5. Keep role-separated request corpora and diff responses across deployments.
+6. Never assume apikey == identity; only JWT binds subject. Prove it.
+7. Prefer concise PoCs: one request per role that clearly shows the unauthorized delta.
+</pro_tips>
+
+<remember>RLS must bind subject and tenant on every path, and server-side code (RPC/Edge) must re-derive identity from a verified token. Any gap in binding, audience/issuer verification, or per-field enforcement becomes a cross-account or cross-tenant vulnerability.</remember>
+</supabase_security_guide>

strix/prompts/vulnerabilities/authentication_jwt.jinja

@@ -1,129 +1,147 @@
 <authentication_jwt_guide>
-<title>AUTHENTICATION & JWT VULNERABILITIES</title>
-
-<critical>Authentication flaws lead to complete account takeover. JWT misconfigurations are everywhere.</critical>
-
-<jwt_structure>
-header.payload.signature
-- Header: {% raw %}{"alg":"HS256","typ":"JWT"}{% endraw %}
-- Payload: {% raw %}{"sub":"1234","name":"John","iat":1516239022}{% endraw %}
-- Signature: HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
-</jwt_structure>
-
-<common_attacks>
-<algorithm_confusion>
-RS256 to HS256:
-- Change RS256 to HS256 in header
-- Use public key as HMAC secret
-- Sign token with public key (often in /jwks.json or /.well-known/)
-</algorithm_confusion>
-
-<none_algorithm>
-- Set {% raw %}"alg": "none"{% endraw %} in header
-- Remove signature completely (keep the trailing dot)
-</none_algorithm>
-
-<weak_secrets>
-Common secrets: 'secret', 'password', '123456', 'key', 'jwt_secret', 'your-256-bit-secret'
-</weak_secrets>
-
-<kid_manipulation>
-- SQL Injection: {% raw %}"kid": "key' UNION SELECT 'secret'--"{% endraw %}
-- Command injection: {% raw %}"kid": "|sleep 10"{% endraw %}
-- Path traversal: {% raw %}"kid": "../../../../../../dev/null"{% endraw %}
-</kid_manipulation>
-</common_attacks>
+<title>AUTHENTICATION AND JWT/OIDC</title>
+
+<critical>JWT/OIDC failures often enable token forgery, token confusion, cross-service acceptance, and durable account takeover. Do not trust headers, claims, or token opacity without strict validation bound to issuer, audience, key, and context.</critical>
+
+<scope>
+- Web/mobile/API authentication using JWT (JWS/JWE) and OIDC/OAuth2
+- Access vs ID tokens, refresh tokens, device/PKCE/Backchannel flows
+- First-party and microservices verification, gateways, and JWKS distribution
+</scope>
+
+<methodology>
+1. Inventory issuers and consumers: identity providers, API gateways, services, mobile/web clients.
+2. Capture real tokens (access and ID) for multiple roles. Note header, claims, signature, and verification endpoints (/.well-known, /jwks.json).
+3. Build a matrix: Token Type × Audience × Service; attempt cross-use (wrong audience/issuer/service) and observe acceptance.
+4. Mutate headers (alg, kid, jku/x5u/jwk, typ/cty/crit), claims (iss/aud/azp/sub/nbf/iat/exp/scope/nonce), and signatures; verify what is actually enforced.
+</methodology>
+
+<discovery_techniques>
+<endpoints>
+- Well-known: /.well-known/openid-configuration, /oauth2/.well-known/openid-configuration
+- Keys: /jwks.json, rotating key endpoints, tenant-specific JWKS
+- Auth: /authorize, /token, /introspect, /revoke, /logout, device code endpoints
+- App: /login, /callback, /refresh, /me, /session, /impersonate
+</endpoints>
+
+<token_features>
+- Headers: {% raw %}{"alg":"RS256","kid":"...","typ":"JWT","jku":"...","x5u":"...","jwk":{...}}{% endraw %}
+- Claims: {% raw %}{"iss":"...","aud":"...","azp":"...","sub":"user","scope":"...","exp":...,"nbf":...,"iat":...}{% endraw %}
+- Formats: JWS (signed), JWE (encrypted). Note unencoded payload option ("b64":false) and critical headers ("crit").
+</token_features>
+</discovery_techniques>
+
+<exploitation_techniques>
+<signature_verification>
+- RS256→HS256 confusion: change alg to HS256 and use the RSA public key as HMAC secret if algorithm is not pinned
+- "none" algorithm acceptance: set {% raw %}"alg":"none"{% endraw %} and drop the signature if libraries accept it
+- ECDSA malleability/misuse: weak verification settings accepting non-canonical signatures
+</signature_verification>
+
+<header_manipulation>
+- kid injection: path traversal {% raw %}../../../../keys/prod.key{% endraw %}, SQL/command/template injection in key lookup, or pointing to world-readable files
+- jku/x5u abuse: host attacker-controlled JWKS/X509 chain; if not pinned/whitelisted, server fetches and trusts attacker keys
+- jwk header injection: embed attacker JWK in header; some libraries prefer inline JWK over server-configured keys
+- SSRF via remote key fetch: exploit JWKS URL fetching to reach internal hosts
+</header_manipulation>
+
+<key_and_cache_issues>
+- JWKS caching TTL and key rollover: accept obsolete keys; race rotation windows; missing kid pinning → accept any matching kty/alg
+- Mixed environments: same secrets across dev/stage/prod; key reuse across tenants or services
+- Fallbacks: verification succeeds when kid not found by trying all keys or no keys (implementation bugs)
+</key_and_cache_issues>
+
+<claims_validation_gaps>
+- iss/aud/azp not enforced: cross-service token reuse; accept tokens from any issuer or wrong audience
+- scope/roles fully trusted from token: server does not re-derive authorization; privilege inflation via claim edits when signature checks are weak
+- exp/nbf/iat not enforced or large clock skew tolerance; accept long-expired or not-yet-valid tokens
+- typ/cty not enforced: accept ID token where access token required (token confusion)
+</claims_validation_gaps>
+
+<token_confusion_and_oidc>
+- Access vs ID token swap: use ID token against APIs when they only verify signature but not audience/typ
+- OIDC mix-up: redirect_uri and client mix-ups causing tokens for Client A to be redeemed at Client B
+- PKCE downgrades: missing S256 requirement; accept plain or absent code_verifier
+- State/nonce weaknesses: predictable or missing → CSRF/logical interception of login\n- Device/Backchannel flows: codes and tokens accepted by unintended clients or services
+</token_confusion_and_oidc>
+
+<refresh_and_session>
+- Refresh token rotation not enforced: reuse old refresh token indefinitely; no reuse detection
+- Long-lived JWTs with no revocation: persistent access post-logout
+- Session fixation: bind new tokens to attacker-controlled session identifiers or cookies
+</refresh_and_session>
+
+<transport_and_storage>
+- Token in localStorage/sessionStorage: susceptible to XSS exfiltration; cookie vs header trade-offs with SameSite/CSRF
+- Insecure CORS: wildcard origins with credentialed requests expose tokens and protected responses
+- TLS and cookie flags: missing Secure/HttpOnly; lack of mTLS or DPoP/"cnf" binding permits replay from another device
+</transport_and_storage>
+</exploitation_techniques>
 
 <advanced_techniques>
-<jwk_injection>
-Embed public key in token header:
-{% raw %}{"jwk": {"kty": "RSA", "n": "your-public-key-n", "e": "AQAB"}}{% endraw %}
-</jwk_injection>
-
-<jku_manipulation>
-Set jku/x5u to attacker-controlled URL hosting malicious JWKS
-</jku_manipulation>
-
-<timing_attacks>
-Extract signature byte-by-byte using verification timing differences
-</timing_attacks>
-</advanced_techniques>
-
-<oauth_vulnerabilities>
-<authorization_code_theft>
-- Exploit redirect_uri with open redirects, subdomain takeover, parameter pollution
-- Missing/predictable state parameter = CSRF
-- PKCE downgrade: remove code_challenge parameter
-</authorization_code_theft>
-</oauth_vulnerabilities>
-
-<saml_attacks>
-- Signature exclusion: remove signature element
-- Signature wrapping: inject assertions
-- XXE in SAML responses
-</saml_attacks>
-
-<session_attacks>
-- Session fixation: force known session ID
-- Session puzzling: mix different session objects
-- Race conditions in session generation
-</session_attacks>
-
-<password_reset_flaws>
-- Predictable tokens: MD5(timestamp), sequential numbers
-- Host header injection for reset link poisoning
-- Race condition resets
-</password_reset_flaws>
-
-<mfa_bypass>
-- Response manipulation: change success:false to true
-- Status code manipulation: 403 to 200
-- Brute force with no rate limiting
-- Backup code abuse
-</mfa_bypass>
-
-<advanced_bypasses>
-<unicode_normalization>
-Different representations: admin@exａmple.com (fullwidth), аdmin@example.com (Cyrillic)
-</unicode_normalization>
-
-<authentication_chaining>
-- JWT + SQLi: kid parameter with SQL injection
-- OAuth + XSS: steal tokens via XSS
-- SAML + XXE + SSRF: chain for internal access
-</authentication_chaining>
-</advanced_bypasses>
-
-<tools>
-- jwt_tool: Comprehensive JWT testing
-- Check endpoints: /login, /oauth/authorize, /saml/login, /.well-known/openid-configuration, /jwks.json
-</tools>
+<microservices_and_gateways>
+- Audience mismatch: internal services verify signature but ignore aud → accept tokens for other services
+- Header trust: edge or gateway injects X-User-Id; backend trusts it over token claims
+- Asynchronous consumers: workers process messages with bearer tokens but skip verification on replay
+</microservices_and_gateways>
+
+<jws_edge_cases>
+- Unencoded payload (b64=false) with crit header: libraries mishandle verification paths
+- Nested JWT (JWT-in-JWT) verification order errors; outer token accepted while inner claims ignored
+</jws_edge_cases>
+
+<special_contexts>
+<mobile>
+- Deep-link/redirect handling bugs leak codes/tokens; insecure WebView bridges exposing tokens
+- Token storage in plaintext files/SQLite/Keychain/SharedPrefs; backup/adb accessible
+</mobile>
+
+<sso_federation>
+- Misconfigured trust between multiple IdPs/SPs, mixed metadata, or stale keys lead to acceptance of foreign tokens
+</sso_federation>
+</special_contexts>
+
+<chaining_attacks>
+- XSS → token theft → replay across services with weak audience checks
+- SSRF → fetch private JWKS → sign tokens accepted by internal services
+- Host header poisoning → OIDC redirect_uri poisoning → code capture
+- IDOR in sessions/impersonation endpoints → mint tokens for other users
+</chaining_attacks>
 
 <validation>
-To confirm authentication flaw:
-1. Demonstrate account access without credentials
-2. Show privilege escalation
-3. Prove token forgery works
-4. Bypass authentication/2FA requirements
-5. Maintain persistent access
+1. Show forged or cross-context token acceptance (wrong alg, wrong audience/issuer, or attacker-signed JWKS).
+2. Demonstrate access token vs ID token confusion at an API.
+3. Prove refresh token reuse without rotation detection or revocation.
+4. Confirm header abuse (kid/jku/x5u/jwk) leading to key selection under attacker control.
+5. Provide owner vs non-owner evidence with identical requests differing only in token context.
 </validation>
 
 <false_positives>
-NOT a vulnerability if:
-- Requires valid credentials
-- Only affects own session
-- Proper signature validation
-- Token expiration enforced
-- Rate limiting prevents brute force
+- Token rejected due to strict audience/issuer enforcement
+- Key pinning with JWKS whitelist and TLS validation
+- Short-lived tokens with rotation and revocation on logout
+- ID token not accepted by APIs that require access tokens
 </false_positives>
 
 <impact>
-- Account takeover: access other users' accounts
-- Privilege escalation: user to admin
-- Token forgery: create valid tokens
-- Bypass mechanisms: skip auth/2FA
-- Persistent access: survives logout
+- Account takeover and durable session persistence
+- Privilege escalation via claim manipulation or cross-service acceptance
+- Cross-tenant or cross-application data access
+- Token minting by attacker-controlled keys or endpoints
 </impact>
 
-<remember>Focus on RS256->HS256, weak secrets, and none algorithm first. Modern apps use multiple auth methods simultaneously - find gaps in integration.</remember>
+<pro_tips>
+1. Pin verification to issuer and audience; log and diff claim sets across services.
+2. Attempt RS256→HS256 and "none" first only if algorithm pinning is unclear; otherwise focus on header key control (kid/jku/x5u/jwk).
+3. Test token reuse across all services; many backends only check signature, not audience/typ.
+4. Exploit JWKS caching and rotation races; try retired keys and missing kid fallbacks.
+5. Exercise OIDC flows with PKCE/state/nonce variants and mixed clients; look for mix-up.
+6. Try DPoP/mTLS absence to replay tokens from different devices.
+7. Treat refresh as its own surface: rotation, reuse detection, and audience scoping.
+8. Validate every acceptance path: gateway, service, worker, WebSocket, and gRPC.
+9. Favor minimal PoCs that clearly show cross-context acceptance and durable access.
+10. When in doubt, assume verification differs per stack (mobile vs web vs gateway) and test each.
+</pro_tips>
+
+<remember>Verification must bind the token to the correct issuer, audience, key, and client context on every acceptance path. Any missing binding enables forgery or confusion.</remember>
 </authentication_jwt_guide>