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

strix/prompts/vulnerabilities/business_logic.jinja

@@ -1,143 +1,171 @@
 <business_logic_flaws_guide>
-<title>BUSINESS LOGIC FLAWS - OUTSMARTING THE APPLICATION</title>
-
-<critical>Business logic flaws bypass all technical security controls by exploiting flawed assumptions in application workflow. Often the highest-paying vulnerabilities.</critical>
+<title>BUSINESS LOGIC FLAWS</title>
+
+<critical>Business logic flaws exploit intended functionality to violate domain invariants: move money without paying, exceed limits, retain privileges, or bypass reviews. They require a model of the business, not just payloads.</critical>
+
+<scope>
+- Financial logic: pricing, discounts, payments, refunds, credits, chargebacks
+- Account lifecycle: signup, upgrade/downgrade, trial, suspension, deletion
+- Authorization-by-logic: feature gates, role transitions, approval workflows
+- Quotas/limits: rate/usage limits, inventory, entitlements, seat licensing
+- Multi-tenant isolation: cross-organization data or action bleed
+- Event-driven flows: jobs, webhooks, sagas, compensations, idempotency
+</scope>
+
+<methodology>
+1. Enumerate a state machine per critical workflow (states, transitions, pre/post-conditions). Note invariants (e.g., "refund ≤ captured amount").
+2. Build an Actor × Action × Resource matrix with at least: unauth, basic user, premium, staff/admin; identify actions per role.
+3. For each transition, test step skipping, repetition, reordering, and late mutation (modify inputs after validation but before commit).
+4. Introduce time, concurrency, and channel variance: repeat with parallel requests, different content-types, mobile/web/API/GraphQL.
+5. Validate persistence boundaries: verify that all services, queues, and jobs re-enforce invariants (no trust in upstream validation).
+</methodology>
 
 <discovery_techniques>
-- Map complete user journeys and state transitions
-- Document developer assumptions
-- Find edge cases in workflows
-- Look for missing validation steps
-- Identify trust boundaries
+<workflow_mapping>
+- Derive endpoints from the UI and proxy/network logs; map hidden/undocumented API calls, especially finalize/confirm endpoints
+- Identify tokens/flags: stepToken, paymentIntentId, orderStatus, reviewState, approvalId; test reuse across users/sessions
+- Document invariants: conservation of value (ledger balance), uniqueness (idempotency), monotonicity (non-decreasing counters), exclusivity (one active subscription)
+</workflow_mapping>
+
+<input_surface>
+- Hidden fields and client-computed totals; server must recompute on trusted sources
+- Alternate encodings and shapes: arrays instead of scalars, objects with unexpected keys, null/empty/0/negative, scientific notation
+- Business selectors: currency, locale, timezone, tax region; vary to trigger rounding and ruleset changes
+</input_surface>
+
+<state_time_axes>
+- Replays: resubmit stale finalize/confirm requests
+- Out-of-order: call finalize before verify; refund before capture; cancel after ship
+- Time windows: end-of-day/month cutovers, daylight saving, grace periods, trial expiry edges
+</state_time_axes>
 </discovery_techniques>
 
 <high_value_targets>
-<financial_workflows>
-- Price manipulation (negative quantities, decimal truncation)
-- Currency conversion abuse (buy weak, refund strong)
-- Discount/coupon stacking
-- Payment method switching after verification
-- Cart manipulation during checkout
-</financial_workflows>
-
-<account_management>
-- Registration race conditions (same email/username)
-- Account type elevation
-- Trial period extension
-- Subscription downgrade with feature retention
-</account_management>
-
-<authorization_flaws>
-- Function-level bypass (accessing admin functions as user)
-- Object reference manipulation
-- Permission inheritance bugs
-- Multi-tenancy isolation failures
-</authorization_flaws>
+- Pricing/cart: price locks, quote to order, tax/shipping computation
+- Discount engines: stacking, mutual exclusivity, scope (cart vs item), once-per-user enforcement
+- Payments: auth/capture/void/refund sequences, partials, split tenders, chargebacks, idempotency keys
+- Credits/gift cards/vouchers: issuance, redemption, reversal, expiry, transferability
+- Subscriptions: proration, upgrade/downgrade, trial extension, seat counts, meter reporting
+- Refunds/returns/RMAs: multi-item partials, restocking fees, return window edges
+- Admin/staff operations: impersonation, manual adjustments, credit/refund issuance, account flags
+- Quotas/limits: daily/monthly usage, inventory reservations, feature usage counters
 </high_value_targets>
 
 <exploitation_techniques>
-<race_conditions>
-Use race conditions to:
-- Double-spend vouchers/credits
-- Bypass rate limits
-- Create duplicate accounts
-- Exploit TOCTOU vulnerabilities
-</race_conditions>
-
-<state_manipulation>
-- Skip workflow steps
-- Replay previous states
-- Force invalid state transitions
-- Manipulate hidden parameters
-</state_manipulation>
-
-<input_manipulation>
-- Type confusion: string where int expected
-- Boundary values: 0, -1, MAX_INT
-- Format abuse: scientific notation, Unicode
-- Encoding tricks: double encoding, mixed encoding
-</input_manipulation>
-</exploitation_techniques>
-
-<common_flaws>
-<shopping_cart>
-- Add items with negative price
-- Modify prices client-side
-- Apply expired coupons
-- Stack incompatible discounts
-- Change currency after price lock
-</shopping_cart>
-
-<payment_processing>
-- Complete order before payment
-- Partial payment acceptance
-- Payment replay attacks
-- Void after delivery
-- Refund more than paid
-</payment_processing>
-
-<user_lifecycle>
-- Premium features in trial
-- Account deletion bypasses
-- Privilege retention after demotion
-- Transfer restrictions bypass
-</user_lifecycle>
-</common_flaws>
+<state_machine_abuse>
+- Skip or reorder steps via direct API calls; verify server enforces preconditions on each transition
+- Replay prior steps with altered parameters (e.g., swap price after approval but before capture)
+- Split a single constrained action into many sub-actions under the threshold (limit slicing)
+</state_machine_abuse>
+
+<concurrency_and_idempotency>
+- Parallelize identical operations to bypass atomic checks (create, apply, redeem, transfer)
+- Abuse idempotency: key scoped to path but not principal → reuse other users' keys; or idempotency stored only in cache
+- Message reprocessing: queue workers re-run tasks on retry without idempotent guards; cause duplicate fulfillment/refund
+</concurrency_and_idempotency>
+
+<numeric_and_currency>
+- Floating point vs decimal rounding; rounding/truncation favoring attacker at boundaries
+- Cross-currency arbitrage: buy in currency A, refund in B at stale rates; tax rounding per-item vs per-order
+- Negative amounts, zero-price, free shipping thresholds, minimum/maximum guardrails
+</numeric_and_currency>
+
+<quotas_limits_inventory>
+- Off-by-one and time-bound resets (UTC vs local); pre-warm at T-1s and post-fire at T+1s
+- Reservation/hold leaks: reserve multiple, complete one, release not enforced; backorder logic inconsistencies
+- Distributed counters without strong consistency enabling double-consumption
+</quotas_limits_inventory>
+
+<refunds_chargebacks>
+- Double-refund: refund via UI and support tool; refund partials summing above captured amount
+- Refund after benefits consumed (downloaded digital goods, shipped items) due to missing post-consumption checks
+</refunds_chargebacks>
+
+<feature_gates_and_roles>
+- Feature flags enforced client-side or at edge but not in core services; toggle names guessed or fallback to default-enabled
+- Role transitions leaving stale capabilities (retain premium after downgrade; retain admin endpoints after demotion)
+</feature_gates_and_roles>
 
 <advanced_techniques>
-<business_constraint_violations>
-- Exceed account limits
-- Bypass geographic restrictions
-- Violate temporal constraints
-- Break dependency chains
-</business_constraint_violations>
-
-<workflow_abuse>
-- Parallel execution of exclusive processes
-- Recursive operations (infinite loops)
-- Asynchronous timing exploitation
-- Callback manipulation
-</workflow_abuse>
-</advanced_techniques>
+<event_driven_sagas>
+- Saga/compensation gaps: trigger compensation without original success; or execute success twice without compensation
+- Outbox/Inbox patterns missing idempotency → duplicate downstream side effects
+- Cron/backfill jobs operating outside request-time authorization; mutate state broadly
+</event_driven_sagas>
+
+<microservices_boundaries>
+- Cross-service assumption mismatch: one service validates total, another trusts line items; alter between calls
+- Header trust: internal services trusting X-Role or X-User-Id from untrusted edges
+- Partial failure windows: two-phase actions where phase 1 commits without phase 2, leaving exploitable intermediate state
+</microservices_boundaries>
+
+<multi_tenant_isolation>
+- Tenant-scoped counters and credits updated without tenant key in the where-clause; leak across orgs
+- Admin aggregate views allowing actions that impact other tenants due to missing per-tenant enforcement
+</multi_tenant_isolation>
+
+<bypass_techniques>
+- Content-type switching (json/form/multipart) to hit different code paths
+- Method alternation (GET performing state change; overrides via X-HTTP-Method-Override)
+- Client recomputation: totals, taxes, discounts computed on client and accepted by server
+- Cache/gateway differentials: stale decisions from CDN/APIM that are not identity-aware
+</bypass_techniques>
+
+<special_contexts>
+<ecommerce>
+- Stack incompatible discounts via parallel apply; remove qualifying item after discount applied; retain free shipping after cart changes
+- Modify shipping tier post-quote; abuse returns to keep product and refund
+</ecommerce>
+
+<banking_fintech>
+- Split transfers to bypass per-transaction threshold; schedule vs instant path inconsistencies
+- Exploit grace periods on holds/authorizations to withdraw again before settlement
+</banking_fintech>
+
+<saas_b2b>
+- Seat licensing: race seat assignment to exceed purchased seats; stale license checks in background tasks
+- Usage metering: report late or duplicate usage to avoid billing or to over-consume
+</saas_b2b>
+</special_contexts>
+
+<chaining_attacks>
+- Business logic + race: duplicate benefits before state updates
+- Business logic + IDOR: operate on others' resources once a workflow leak reveals IDs
+- Business logic + CSRF: force a victim to complete a sensitive step sequence
+</chaining_attacks>
 
 <validation>
-To confirm business logic flaw:
-1. Demonstrate financial impact
-2. Show consistent reproduction
-3. Prove bypass of intended restrictions
-4. Document assumption violation
-5. Quantify potential damage
+1. Show an invariant violation (e.g., two refunds for one charge, negative inventory, exceeding quotas).
+2. Provide side-by-side evidence for intended vs abused flows with the same principal.
+3. Demonstrate durability: the undesired state persists and is observable in authoritative sources (ledger, emails, admin views).
+4. Quantify impact per action and at scale (unit loss × feasible repetitions).
 </validation>
 
 <false_positives>
-NOT a business logic flaw if:
-- Requires technical vulnerability (SQLi, XSS)
-- Working as designed (bad design ≠ vulnerability)
-- Only affects display/UI
-- No security impact
-- Requires privileged access
+- Promotional behavior explicitly allowed by policy (documented free trials, goodwill credits)
+- Visual-only inconsistencies with no durable or exploitable state change
+- Admin-only operations with proper audit and approvals
 </false_positives>
 
 <impact>
-- Financial loss (direct monetary impact)
-- Unauthorized access to features/data
-- Service disruption
-- Compliance violations
-- Reputation damage
+- Direct financial loss (fraud, arbitrage, over-refunds, unpaid consumption)
+- Regulatory/contractual violations (billing accuracy, consumer protection)
+- Denial of inventory/services to legitimate users through resource exhaustion
+- Privilege retention or unauthorized access to premium features
 </impact>
 
 <pro_tips>
-1. Think like a malicious user, not a developer
-2. Question every assumption
-3. Test boundary conditions obsessively
-4. Combine multiple small issues
-5. Focus on money flows
-6. Check state machines thoroughly
-7. Abuse features, don't break them
-8. Document business impact clearly
-9. Test integration points
-10. Time is often a factor - exploit it
+1. Start from invariants and ledgers, not UI—prove conservation of value breaks.
+2. Test with time and concurrency; many bugs only appear under pressure.
+3. Recompute totals server-side; never accept client math—flag when you observe otherwise.
+4. Treat idempotency and retries as first-class: verify key scope and persistence.
+5. Probe background workers and webhooks separately; they often skip auth and rule checks.
+6. Validate role/feature gates at the service that mutates state, not only at the edge.
+7. Explore end-of-period edges (month-end, trial end, DST) for rounding and window issues.
+8. Use minimal, auditable PoCs that demonstrate durable state change and exact loss.
+9. Chain with authorization tests (IDOR/Function-level access) to magnify impact.
+10. When in doubt, map the state machine; gaps appear where transitions lack server-side guards.
 </pro_tips>
 
-<remember>Business logic flaws are about understanding and exploiting the application's rules, not breaking them with technical attacks. The best findings come from deep understanding of the business domain.</remember>
+<remember>Business logic security is the enforcement of domain invariants under adversarial sequencing, timing, and inputs. If any step trusts the client or prior steps, expect abuse.</remember>
 </business_logic_flaws_guide>

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>