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

strix/prompts/vulnerabilities/csrf.jinja

@@ -1,168 +1,174 @@
 <csrf_vulnerability_guide>
-<title>CROSS-SITE REQUEST FORGERY (CSRF) - ADVANCED EXPLOITATION</title>
+<title>CROSS-SITE REQUEST FORGERY (CSRF)</title>
 
-<critical>CSRF forces authenticated users to execute unwanted actions, exploiting the trust a site has in the user's browser.</critical>
+<critical>CSRF abuses ambient authority (cookies, HTTP auth) across origins. Do not rely on CORS alone; enforce non-replayable tokens and strict origin checks for every state change.</critical>
+
+<scope>
+- Web apps with cookie-based sessions and HTTP auth
+- JSON/REST, GraphQL (GET/persisted queries), file upload endpoints
+- Authentication flows: login/logout, password/email change, MFA toggles
+- OAuth/OIDC: authorize, token, logout, disconnect/connect
+</scope>
+
+<methodology>
+1. Inventory all state-changing endpoints (including admin/staff) and note method, content-type, and whether they are reachable via top-level navigation or simple requests (no preflight).
+2. For each, determine session model (cookies with SameSite attrs, custom headers, tokens) and whether server enforces anti-CSRF tokens and Origin/Referer.
+3. Attempt preflightless delivery (form POST, text/plain, multipart/form-data) and top-level GET navigation.
+4. Validate across browsers; behavior differs by SameSite and navigation context.
+</methodology>
 
 <high_value_targets>
-- Password/email change forms
-- Money transfer/payment functions
-- Account deletion/deactivation
-- Permission/role changes
-- API key generation/regeneration
-- OAuth connection/disconnection
-- 2FA enable/disable
-- Privacy settings modification
-- Admin functions
-- File uploads/deletions
+- Credentials and profile changes (email/password/phone)
+- Payment and money movement, subscription/plan changes
+- API key/secret generation, PAT rotation, SSH keys
+- 2FA/TOTP enable/disable; backup codes; device trust
+- OAuth connect/disconnect; logout; account deletion
+- Admin/staff actions and impersonation flows
+- File uploads/deletes; access control changes
 </high_value_targets>
 
 <discovery_techniques>
-<token_analysis>
-Common token names: csrf_token, csrftoken, _csrf, authenticity_token, __RequestVerificationToken, X-CSRF-TOKEN
-
-Check if tokens are:
-- Actually validated (remove and test)
-- Tied to user session
-- Reusable across requests
-- Present in GET requests
-- Predictable or static
-</token_analysis>
-
-<http_methods>
-- Test if POST endpoints accept GET
-- Try method override headers: _method, X-HTTP-Method-Override
-- Check if PUT/DELETE lack protection
-</http_methods>
+<session_and_cookies>
+- Inspect cookies: HttpOnly, Secure, SameSite (Strict/Lax/None). Note that Lax allows cookies on top-level cross-site GET; None requires Secure.
+- Determine if Authorization headers or bearer tokens are used (generally not CSRF-prone) versus cookies (CSRF-prone).
+</session_and_cookies>
+
+<token_and_header_checks>
+- Locate anti-CSRF tokens (hidden inputs, meta tags, custom headers). Test removal, reuse across requests, reuse across sessions, and binding to method/path.
+- Verify server checks Origin and/or Referer on state changes; test null/missing and cross-origin values.
+</token_and_header_checks>
+
+<method_and_content_types>
+- Confirm whether GET, HEAD, or OPTIONS perform state changes.
+- Try simple content-types to avoid preflight: application/x-www-form-urlencoded, multipart/form-data, text/plain.
+- Probe parsers that auto-coerce text/plain or form-encoded bodies into JSON.
+</method_and_content_types>
+
+<cors_profile>
+- Identify Access-Control-Allow-Origin and -Credentials. Overly permissive CORS is not a CSRF fix and can turn CSRF into data exfiltration.
+- Test per-endpoint CORS differences; preflight vs simple request behavior can diverge.
+</cors_profile>
 </discovery_techniques>
 
 <exploitation_techniques>
-<basic_forms>
-HTML form auto-submit:
-<form action="https://target.com/transfer" method="POST">
-  <input name="amount" value="1000">
-  <input name="to" value="attacker">
-</form>
-<script>document.forms[0].submit()</script>
-</basic_forms>
+<navigation_csrf>
+- Auto-submitting form to target origin; works when cookies are sent and no token/origin checks are enforced.
+- Top-level GET navigation can trigger state if server misuses GET or links actions to GET callbacks.
+</navigation_csrf>
+
+<simple_ct_csrf>
+- application/x-www-form-urlencoded and multipart/form-data POSTs do not require preflight; prefer these encodings.
+- text/plain form bodies can slip through validators and be parsed server-side.
+</simple_ct_csrf>
 
 <json_csrf>
-For JSON endpoints:
-<form enctype="text/plain" action="https://target.com/api">
-  <input name='{% raw %}{"amount":1000,"to":"attacker","ignore":"{% endraw %}' value='"}'>
-</form>
+- If server parses JSON from text/plain or form-encoded bodies, craft parameters to reconstruct JSON server-side.
+- Some frameworks accept JSON keys via form fields (e.g., {% raw %}data[foo]=bar{% endraw %}) or treat duplicate keys leniently.
 </json_csrf>
 
-<multipart_csrf>
-For file uploads:
-Use XMLHttpRequest with credentials
-Generate multipart/form-data boundaries
-</multipart_csrf>
-</exploitation_techniques>
+<login_logout_csrf>
+- Force logout to clear CSRF tokens, then chain login CSRF to bind victim to attacker’s account.
+- Login CSRF: submit attacker credentials to victim’s browser; later actions occur under attacker’s account.
+</login_logout_csrf>
 
-<bypass_techniques>
-<token_bypasses>
-- Null token: remove parameter entirely
-- Empty token: csrf_token=
-- Token from own account: use your valid token
-- Token fixation: force known token value
-- Method interchange: GET token used for POST
-</token_bypasses>
-
-<header_bypasses>
-- Referer bypass: use data: URI, about:blank
-- Origin bypass: null origin via sandboxed iframe
-- CORS misconfigurations
-</header_bypasses>
-
-<content_type_tricks>
-- Change multipart to application/x-www-form-urlencoded
-- Use text/plain for JSON endpoints
-- Exploit parsers that accept multiple formats
-</content_type_tricks>
-</bypass_techniques>
+<oauth_oidc_flows>
+- Abuse authorize/logout endpoints reachable via GET or form POST without origin checks; exploit relaxed SameSite on top-level navigations.
+- Open redirects or loose redirect_uri validation can chain with CSRF to force unintended authorizations.
+</oauth_oidc_flows>
+
+<file_and_action_endpoints>
+- File upload/delete often lack token checks; forge multipart requests to modify storage.
+- Admin actions exposed as simple POST links are frequently CSRFable.
+</file_and_action_endpoints>
+</exploitation_techniques>
 
 <advanced_techniques>
-<subdomain_csrf>
-- XSS on subdomain = CSRF on main domain
-- Cookie scope abuse (domain=.example.com)
-- Subdomain takeover for CSRF
-</subdomain_csrf>
-
-<csrf_login>
-- Force victim to login as attacker
-- Plant backdoors in victim's account
-- Access victim's future data
-</csrf_login>
-
-<csrf_logout>
-- Force logout → login CSRF → account takeover
-</csrf_logout>
-
-<double_submit_csrf>
-If using double-submit cookies:
-- Set cookie via XSS/subdomain
-- Cookie injection via header injection
-- Cookie tossing attacks
-</double_submit_csrf>
-</advanced_techniques>
+<samesite_nuance>
+- Lax-by-default cookies are sent on top-level cross-site GET but not POST; exploit GET state changes and GET-based confirmation steps.
+- Legacy or nonstandard clients may ignore SameSite; validate across browsers/devices.
+</samesite_nuance>
 
-<special_contexts>
-<websocket_csrf>
-- Cross-origin WebSocket hijacking
-- Steal tokens from WebSocket messages
-</websocket_csrf>
+<origin_referer_obfuscation>
+- Sandbox/iframes can produce null Origin; some frameworks incorrectly accept null.
+- about:blank/data: URLs alter Referer; ensure server requires explicit Origin/Referer match.
+</origin_referer_obfuscation>
+
+<method_override>
+- Backends honoring _method or X-HTTP-Method-Override may allow destructive actions through a simple POST.
+</method_override>
 
 <graphql_csrf>
-- GET requests with query parameter
-- Batched mutations
-- Subscription abuse
+- If queries/mutations are allowed via GET or persisted queries, exploit top-level navigation with encoded payloads.
+- Batched operations may hide mutations within a nominally safe request.
 </graphql_csrf>
 
-<api_csrf>
-- Bearer tokens in URL parameters
-- API keys in GET requests
-- Insecure CORS policies
-</api_csrf>
+<websocket_csrf>
+- Browsers send cookies on WebSocket handshake; enforce Origin checks server-side. Without them, cross-site pages can open authenticated sockets and issue actions.
+</websocket_csrf>
+</advanced_techniques>
+
+<bypass_techniques>
+<token_weaknesses>
+- Accepting missing/empty tokens; tokens not tied to session, user, or path; tokens reused indefinitely; tokens in GET.
+- Double-submit cookie without Secure/HttpOnly, or with predictable token sources.
+</token_weaknesses>
+
+<content_type_switching>
+- Switch between form, multipart, and text/plain to reach different code paths and validators.
+- Use duplicate keys and array shapes to confuse parsers.
+</content_type_switching>
+
+<header_manipulation>
+- Strip Referer via meta refresh or navigate from about:blank; test null Origin acceptance.
+- Leverage misconfigured CORS to add custom headers that servers mistakenly treat as CSRF tokens.
+</header_manipulation>
+</bypass_techniques>
+
+<special_contexts>
+<mobile_spa>
+- Deep links and embedded WebViews may auto-send cookies; trigger actions via crafted intents/links.
+- SPAs that rely solely on bearer tokens are less CSRF-prone, but hybrid apps mixing cookies and APIs can still be vulnerable.
+</mobile_spa>
+
+<integrations>
+- Webhooks and back-office tools sometimes expose state-changing GETs intended for staff; confirm CSRF defenses there too.
+</integrations>
 </special_contexts>
 
+<chaining_attacks>
+- CSRF + IDOR: force actions on other users' resources once references are known.
+- CSRF + Clickjacking: guide user interactions to bypass UI confirmations.
+- CSRF + OAuth mix-up: bind victim sessions to unintended clients.
+</chaining_attacks>
+
 <validation>
-To confirm CSRF:
-1. Create working proof-of-concept
-2. Test across browsers
-3. Verify action completes successfully
-4. No user interaction required (beyond visiting page)
-5. Works with active session
+1. Demonstrate a cross-origin page that triggers a state change without user interaction beyond visiting.
+2. Show that removing the anti-CSRF control (token/header) is accepted, or that Origin/Referer are not verified.
+3. Prove behavior across at least two browsers or contexts (top-level nav vs XHR/fetch).
+4. Provide before/after state evidence for the same account.
+5. If defenses exist, show the exact condition under which they are bypassed (content-type, method override, null Origin).
 </validation>
 
 <false_positives>
-NOT CSRF if:
-- Requires valid CSRF token
-- SameSite cookies properly configured
-- Proper origin/referer validation
-- User interaction required
-- Only affects non-sensitive actions
+- Token verification present and required; Origin/Referer enforced consistently.
+- No cookies sent on cross-site requests (SameSite=Strict, no HTTP auth) and no state change via simple requests.
+- Only idempotent, non-sensitive operations affected.
 </false_positives>
 
 <impact>
-- Account takeover
-- Financial loss
-- Data modification/deletion
-- Privilege escalation
-- Privacy violations
+- Account state changes (email/password/MFA), session hijacking via login CSRF, financial operations, administrative actions.
+- Durable authorization changes (role/permission flips, key rotations) and data loss.
 </impact>
 
 <pro_tips>
-1. Check all state-changing operations
-2. Test file upload endpoints
-3. Look for token disclosure in URLs
-4. Chain with XSS for token theft
-5. Check mobile API endpoints
-6. Test CORS configurations
-7. Verify SameSite cookie settings
-8. Look for method override possibilities
-9. Test WebSocket endpoints
-10. Document clear attack scenario
+1. Prefer preflightless vectors (form-encoded, multipart, text/plain) and top-level GET if available.
+2. Test login/logout, OAuth connect/disconnect, and account linking first.
+3. Validate Origin/Referer behavior explicitly; do not assume frameworks enforce them.
+4. Toggle SameSite and observe differences across navigation vs XHR.
+5. For GraphQL, attempt GET queries or persisted queries that carry mutations.
+6. Always try method overrides and parser differentials.
+7. Combine with clickjacking when visual confirmations block CSRF.
 </pro_tips>
 
-<remember>Modern CSRF requires creativity - look for token leaks, chain with other vulnerabilities, and focus on high-impact actions. SameSite cookies are not always properly configured.</remember>
+<remember>CSRF is eliminated only when state changes require a secret the attacker cannot supply and the server verifies the caller’s origin. Tokens and Origin checks must hold across methods, content-types, and transports.</remember>
 </csrf_vulnerability_guide>

strix/prompts/vulnerabilities/idor.jinja

@@ -1,164 +1,195 @@
 <idor_vulnerability_guide>
-<title>INSECURE DIRECT OBJECT REFERENCE (IDOR) - ELITE TECHNIQUES</title>
+<title>INSECURE DIRECT OBJECT REFERENCE (IDOR)</title>
 
-<critical>IDORs are among the HIGHEST IMPACT vulnerabilities - direct unauthorized data access and account takeover.</critical>
+<critical>Object- and function-level authorization failures (BOLA/IDOR) routinely lead to cross-account data exposure and unauthorized state changes across APIs, web, mobile, and microservices. Treat every object reference as untrusted until proven bound to the caller.</critical>
+
+<scope>
+- Horizontal access: access another subject's objects of the same type
+- Vertical access: access privileged objects/actions (admin-only, staff-only)
+- Cross-tenant access: break isolation boundaries in multi-tenant systems
+- Cross-service access: token or context accepted by the wrong service
+</scope>
+
+<methodology>
+1. Build a Subject × Object × Action matrix (who can do what to which resource).
+2. For each resource type, obtain at least two principals: owner and non-owner (plus admin/staff if applicable). Capture at least one valid object ID per principal.
+3. Exercise every action (R/W/D/Export) while swapping IDs, tokens, tenants, and channels (web, mobile, API, GraphQL, WebSocket, gRPC).
+4. Track consistency: the same rule must hold regardless of transport, content-type, serialization, or gateway.
+</methodology>
 
 <discovery_techniques>
 <parameter_analysis>
-- Numeric IDs: user_id=123, account=456
-- UUID/GUID patterns: id=550e8400-e29b-41d4-a716-446655440000
-- Encoded IDs: Base64, hex, custom encoding
-- Composite IDs: user-org-123-456, ACCT:2024:00123
-- Hash-based IDs: Check if predictable (MD5 of sequential numbers)
-- Object references in: URLs, POST bodies, headers, cookies, JWT tokens
+- Object references appear in: paths, query params, JSON bodies, form-data, headers, cookies, JWT claims, GraphQL arguments, WebSocket messages, gRPC messages
+- Identifier forms: integers, UUID/ULID/CUID, Snowflake, slugs, composite keys (e.g., {orgId}:{userId}), opaque tokens, base64/hex-encoded blobs
+- Relationship references: parentId, ownerId, accountId, tenantId, organization, teamId, projectId, subscriptionId
+- Expansion/projection knobs: fields, include, expand, projection, with, select, populate (often bypass authorization in resolvers or serializers)
+- Pagination/cursors: page[offset], page[limit], cursor, nextPageToken (often reveal or accept cross-tenant/state)
 </parameter_analysis>
 
 <advanced_enumeration>
-- Boundary values: 0, -1, null, empty string, max int
-- Different formats: {% raw %}{"id":123} vs {"id":"123"}{% endraw %}
-- ID patterns: increment, decrement, similar patterns
-- Wildcard testing: *, %, _, all
-- Array notation: id[]=123&id[]=456
+- Alternate types: {% raw %}{"id":123}{% endraw} vs {% raw %}{"id":"123"}{% endraw}, arrays vs scalars, objects vs scalars, null/empty/0/-1/MAX_INT, scientific notation, overflows, unknown attributes retained by backend
+- Duplicate keys/parameter pollution: id=1&id=2, JSON duplicate keys {% raw %}{"id":1,"id":2}{% endraw} (parser precedence differences)
+- Case/aliasing: userId vs userid vs USER_ID; alt names like resourceId, targetId, account
+- Path traversal-like in virtual file systems: /files/user_123/../../user_456/report.csv
+- Directory/list endpoints as seeders: search/list/suggest/export often leak object IDs for secondary exploitation
 </advanced_enumeration>
 </discovery_techniques>
 
 <high_value_targets>
-- User profiles and PII
-- Financial records/transactions
-- Private messages/communications
-- Medical records
-- API keys/secrets
-- Internal documents
-- Admin functions
-- Export endpoints
-- Backup files
-- Debug information
+- Exports/backups/reporting endpoints (CSV/PDF/ZIP)
+- Messaging/mailbox/notifications, audit logs, activity feeds
+- Billing: invoices, payment methods, transactions, credits
+- Healthcare/education records, HR documents, PII/PHI/PCI
+- Admin/staff tools, impersonation/session management
+- File/object storage keys (S3/GCS signed URLs, share links)
+- Background jobs: import/export job IDs, task results
+- Multi-tenant resources: organizations, workspaces, projects
 </high_value_targets>
 
 <exploitation_techniques>
-<direct_access>
-Simple increment/decrement:
-/api/user/123 → /api/user/124
-/download?file=report_2024_01.pdf → report_2024_02.pdf
-</direct_access>
-
-<mass_enumeration>
-Automate ID ranges:
-for i in range(1, 10000):
-    /api/user/{i}/data
-</mass_enumeration>
-
-<type_confusion>
-- String where int expected: "123" vs 123
-- Array where single value expected: [123] vs 123
-- Object injection: {% raw %}{"id": {"$ne": null}}{% endraw %}
-</type_confusion>
-</exploitation_techniques>
+<horizontal_vertical>
+- Swap object IDs between principals using the same token to probe horizontal access; then repeat with lower-privilege tokens to probe vertical access
+- Target partial updates (PATCH, JSON Patch/JSON Merge Patch) for silent unauthorized modifications
+</horizontal_vertical>
 
-<advanced_techniques>
-<uuid_prediction>
-- Time-based UUIDs (version 1): predictable timestamps
-- Weak randomness in version 4
-- Sequential UUID generation
-</uuid_prediction>
-
-<blind_idor>
-- Side channel: response time, size differences
-- Error message variations
-- Boolean-based: exists vs not exists
-</blind_idor>
+<bulk_and_batch>
+- Batch endpoints (bulk update/delete) often validate only the first element; include cross-tenant IDs mid-array
+- CSV/JSON imports referencing foreign object IDs (ownerId, orgId) may bypass create-time checks
+</bulk_and_batch>
 
 <secondary_idor>
-First get list of IDs, then access:
-/api/users → [123, 456, 789]
-/api/user/789/private-data
+- Use list/search endpoints, notifications, emails, webhooks, and client logs to collect valid IDs, then fetch or mutate those objects directly
+- Pagination/cursor manipulation to skip filters and pull other users' pages
 </secondary_idor>
+
+<job_task_objects>
+- Access job/task IDs from one user to retrieve results for another (export/{jobId}/download, reports/{taskId})
+- Cancel/approve someone else's jobs by referencing their task IDs
+</job_task_objects>
+
+<file_object_storage>
+- Direct object paths or weakly scoped signed URLs; attempt key prefix changes, content-disposition tricks, or stale signatures reused across tenants
+- Replace share tokens with tokens from other tenants; try case/URL-encoding variations
+</file_object_storage>
+</exploitation_techniques>
+
+<advanced_techniques>
+<graphql>
+- Enforce resolver-level checks: do not rely on a top-level gate. Verify field and edge resolvers bind the resource to the caller on every hop
+- Abuse batching/aliases to retrieve multiple users' nodes in one request and compare responses
+- Global node patterns (Relay): decode base64 IDs and swap raw IDs; test {% raw %}node(id: "...base64..."){...}{% endraw %}
+- Overfetching via fragments on privileged types; verify hidden fields cannot be queried by unprivileged callers
+- Example:
+{% raw %}
+query IDOR {
+  me { id }
+  u1: user(id: "VXNlcjo0NTY=") { email billing { last4 } }
+  u2: node(id: "VXNlcjo0NTc=") { ... on User { email } }
+}
+{% endraw %}
+</graphql>
+
+<microservices_gateways>
+- Token confusion: a token scoped for Service A accepted by Service B due to shared JWT verification but missing audience/claims checks
+- Trust on headers: reverse proxies or API gateways injecting/trusting headers like X-User-Id, X-Organization-Id; try overriding or removing them
+- Context loss: async consumers (queues, workers) re-process requests without re-checking authorization
+</microservices_gateways>
+
+<multi_tenant>
+- Probe tenant scoping through headers, subdomains, and path params (e.g., X-Tenant-ID, org slug). Try mixing org of token with resource from another org
+- Test cross-tenant reports/analytics rollups and admin views which aggregate multiple tenants
+</multi_tenant>
+
+<uuid_and_opaque_ids>
+- UUID/ULID are not authorization: acquire valid IDs from logs, exports, JS bundles, analytics endpoints, emails, or public activity, then test ownership binding
+- Time-based IDs (UUIDv1, ULID) may be guessable within a window; combine with leakage sources for targeted access
+</uuid_and_opaque_ids>
+
+<blind_channels>
+- Use differential responses (status, size, ETag, timing) to detect existence; error shape often differs for owned vs foreign objects
+- HEAD/OPTIONS, conditional requests (If-None-Match/If-Modified-Since) can confirm existence without full content
+</blind_channels>
 </advanced_techniques>
 
 <bypass_techniques>
+<parser_and_transport>
+- Content-type switching: application/json ↔ application/x-www-form-urlencoded ↔ multipart/form-data; some paths enforce checks per parser
+- Method tunneling: X-HTTP-Method-Override, _method=PATCH; or using GET on endpoints incorrectly accepting state changes
+- JSON duplicate keys/array injection to bypass naive validators
+</parser_and_transport>
+
 <parameter_pollution>
-?id=123&id=456 (takes last or first?)
-?user_id=victim&user_id=attacker
+- Duplicate parameters in query/body to influence server-side precedence (id=123&id=456); try both orderings
+- Mix case/alias param names so gateway and backend disagree (userId vs userid)
 </parameter_pollution>
 
-<encoding_tricks>
-- URL encode: %31%32%33
-- Double encoding: %25%33%31
-- Unicode: \u0031\u0032\u0033
-</encoding_tricks>
-
-<case_variation>
-userId vs userid vs USERID vs UserId
-</case_variation>
-
-<format_switching>
-/api/user.json?id=123
-/api/user.xml?id=123
-/api/user/123.json vs /api/user/123
-</format_switching>
+<cache_and_gateway>
+- CDN/proxy key confusion: responses keyed without Authorization or tenant headers expose cached objects to other users; manipulate Vary and Accept
+- Redirect chains and 304/206 behaviors can leak content across tenants
+</cache_and_gateway>
+
+<race_windows>
+- Time-of-check vs time-of-use: change the referenced ID between validation and execution using parallel requests
+</race_windows>
 </bypass_techniques>
 
 <special_contexts>
-<graphql_idor>
-Query batching and alias abuse:
-query { u1: user(id: 123) { data } u2: user(id: 456) { data } }
-</graphql_idor>
-
-<websocket_idor>
-Subscribe to other users' channels:
-{% raw %}{"subscribe": "user_456_notifications"}{% endraw %}
-</websocket_idor>
-
-<file_path_idor>
-../../../other_user/private.pdf
-/files/user_123/../../user_456/data.csv
-</file_path_idor>
+<websocket>
+- Authorization per-subscription: ensure channel/topic names cannot be guessed (user_{id}, org_{id}); subscribe/publish checks must run server-side, not only at handshake
+- Try sending messages with target user IDs after subscribing to own channels
+</websocket>
+
+<grpc>
+- Direct protobuf fields (owner_id, tenant_id) often bypass HTTP-layer middleware; validate references via grpcurl with tokens from different principals
+</grpc>
+
+<integrations>
+- Webhooks/callbacks referencing foreign objects (e.g., invoice_id) processed without verifying ownership
+- Third-party importers syncing data into wrong tenant due to missing tenant binding
+</integrations>
 </special_contexts>
 
 <chaining_attacks>
-- IDOR + XSS: Access and weaponize other users' data
-- IDOR + CSRF: Force actions on discovered objects
-- IDOR + SQLi: Extract all IDs then access
+- IDOR + CSRF: force victims to trigger unauthorized changes on objects you discovered
+- IDOR + Stored XSS: pivot into other users' sessions through data you gained access to
+- IDOR + SSRF: exfiltrate internal IDs, then access their corresponding resources
+- IDOR + Race: bypass spot checks with simultaneous requests
 </chaining_attacks>
 
 <validation>
-To confirm IDOR:
-1. Access data/function without authorization
-2. Demonstrate data belongs to another user
-3. Show consistent access pattern
-4. Prove it's not intended functionality
-5. Document security impact
+1. Demonstrate access to an object not owned by the caller (content or metadata).
+2. Show the same request fails with appropriately enforced authorization when corrected.
+3. Prove cross-channel consistency: same unauthorized access via at least two transports (e.g., REST and GraphQL).
+4. Document tenant boundary violations (if applicable).
+5. Provide reproducible steps and evidence (requests/responses for owner vs non-owner).
 </validation>
 
 <false_positives>
-NOT IDOR if:
-- Public data by design
-- Proper authorization checks
-- Only affects own resources
-- Rate limiting prevents exploitation
-- Data is sanitized/limited
+- Public/anonymous resources by design
+- Soft-privatized data where content is already public
+- Idempotent metadata lookups that do not reveal sensitive content
+- Correct row-level checks enforced across all channels
 </false_positives>
 
 <impact>
-- Personal data exposure
-- Financial information theft
-- Account takeover
-- Business data leak
-- Compliance violations (GDPR, HIPAA)
+- Cross-account data exposure (PII/PHI/PCI)
+- Unauthorized state changes (transfers, role changes, cancellations)
+- Cross-tenant data leaks violating contractual and regulatory boundaries
+- Regulatory risk (GDPR/HIPAA/PCI), fraud, reputational damage
 </impact>
 
 <pro_tips>
-1. Test all ID parameters systematically
-2. Look for patterns in IDs
-3. Check export/download functions
-4. Test different HTTP methods
-5. Monitor for blind IDOR via timing
-6. Check mobile APIs separately
-7. Look for backup/debug endpoints
-8. Test file path traversal
-9. Automate enumeration carefully
-10. Chain with other vulnerabilities
+1. Always test list/search/export endpoints first; they are rich ID seeders.
+2. Build a reusable ID corpus from logs, notifications, emails, and client bundles.
+3. Toggle content-types and transports; authorization middleware often differs per stack.
+4. In GraphQL, validate at resolver boundaries; never trust parent auth to cover children.
+5. In multi-tenant apps, vary org headers, subdomains, and path params independently.
+6. Check batch/bulk operations and background job endpoints; they frequently skip per-item checks.
+7. Inspect gateways for header trust and cache key configuration.
+8. Treat UUIDs as untrusted; obtain them via OSINT/leaks and test binding.
+9. Use timing/size/ETag differentials for blind confirmation when content is masked.
+10. Prove impact with precise before/after diffs and role-separated evidence.
 </pro_tips>
 
-<remember>IDORs are about broken access control, not just guessable IDs. Even GUIDs can be vulnerable if disclosed elsewhere. Focus on high-impact data access.</remember>
+<remember>Authorization must bind subject, action, and specific object on every request, regardless of identifier opacity or transport. If the binding is missing anywhere, the system is vulnerable.</remember>
 </idor_vulnerability_guide>