strix-agent 0.4.0__py3-none-any.whl

strix/prompts/protocols/graphql.jinja

@@ -0,0 +1,215 @@
+<graphql_protocol_guide>
+<title>GRAPHQL — ADVANCED TESTING AND EXPLOITATION</title>
+
+<critical>GraphQL’s flexibility enables powerful data access, but also unique failures: field- and edge-level authorization drift, schema exposure (even with introspection off), alias/batch abuse, resolver injection, federated trust gaps, and complexity/fragment bombs. Bind subject→action→object at resolver boundaries and validate across every transport and feature flag.</critical>
+
+<scope>
+- Queries, mutations, subscriptions (graphql-ws, graphql-transport-ws)
+- Persisted queries/Automatic Persisted Queries (APQ)
+- Federation (Apollo/GraphQL Mesh): _service SDL and _entities
+- File uploads (GraphQL multipart request spec)
+- Relay conventions: global node IDs, connections/cursors
+</scope>
+
+<methodology>
+1. Fingerprint endpoint(s), transport(s), and stack (framework, plugins, gateway). Note GraphiQL/Playground exposure and CORS/credentials.
+2. Obtain multiple principals (unauth, basic, premium, admin/staff) and capture at least one valid object ID per subject.
+3. Acquire schema via introspection; if disabled, infer iteratively from errors, field suggestions, __typename probes, vocabulary brute-force.
+4. Build an Actor × Operation × Type/Field matrix. Exercise each resolver path with swapped IDs, roles, tenants, and channels (REST proxies, GraphQL HTTP, WS).
+5. Validate consistency: same authorization and validation across queries, mutations, subscriptions, batch/alias, persisted queries, and federation.
+</methodology>
+
+<discovery_techniques>
+<endpoint_finding>
+- Common paths: /graphql, /api/graphql, /v1/graphql, /gql
+- Probe with minimal canary:
+{% raw %}
+POST /graphql {"query":"{__typename}"}
+GET  /graphql?query={__typename}
+{% endraw %}
+- Detect GraphiQL/Playground; note if accessible cross-origin and with credentials.
+</endpoint_finding>
+
+<introspection_and_inference>
+- If enabled, dump full schema; otherwise:
+  - Use __typename on candidate fields to confirm types
+  - Abuse field suggestions and error shapes to enumerate names/args
+  - Infer enums from “expected one of” errors; coerce types by providing wrong shapes
+  - Reconstruct edges from pagination and connection hints (pageInfo, edges/node)
+</introspection_and_inference>
+
+<schema_construction>
+- Map root operations, object types, interfaces/unions, directives (@auth, @defer, @stream), and custom scalars (Upload, JSON, DateTime)
+- Identify sensitive fields: email, tokens, roles, billing, file keys, admin flags
+- Note cascade paths where child resolvers may skip auth under parent assumptions
+</schema_construction>
+</discovery_techniques>
+
+<exploitation_techniques>
+<authorization_and_idor>
+- Test field-level and edge-level checks, not just top-level gates. Pair owned vs foreign IDs within the same request via aliases to diff responses.
+{% raw %}
+query {
+  me { id }
+  a: order(id:"A_OWNER") { id total owner { id email } }
+  b: order(id:"B_FOREIGN") { id total owner { id email } }
+}
+{% endraw %}
+- Probe mutations for partial updates that bypass validation (JSON Merge Patch semantics in inputs).
+- Validate node/global ID resolvers (Relay) bind to the caller; decode/replace base64 IDs and compare access.
+</authorization_and_idor>
+
+<batching_and_alias>
+- Alias to perform many logically separate reads in one operation; watch for per-request vs per-field auth discrepancies
+- If array batching is supported (non-standard), submit multiple operations to bypass rate limits and achieve partial failures
+{% raw %}
+query {
+  u1:user(id:"1"){email}
+  u2:user(id:"2"){email}
+  u3:user(id:"3"){email}
+}
+{% endraw %}
+</batching_and_alias>
+
+<variable_and_shape_abuse>
+- Scalars vs objects vs arrays: {% raw %}{id:123}{% endraw} vs {% raw %}{id:"123"}{% endraw} vs {% raw %}{id:[123]}{% endraw}; send null/empty/0/-1 and extra object keys retained by backend
+- Duplicate keys in JSON variables: {% raw %}{"id":1,"id":2}{% endraw} (parser precedence), default argument values, coercion errors leaking field names
+</variable_and_shape_abuse>
+
+<cursor_and_projection>
+- Decode cursors (often base64) to manipulate offsets/IDs and skip filters
+- Abuse selection sets and fragments to force overfetching of sensitive subfields
+</cursor_and_projection>
+
+<file_uploads>
+- GraphQL multipart: test multiple Upload scalars, filename/path tricks, unexpected content-types, oversize chunks; verify server-side ownership/scoping for returned URLs
+</file_uploads>
+</exploitation_techniques>
+
+<advanced_techniques>
+<introspection_bypass>
+- Field suggestion leakage: submit near-miss names to harvest suggestions
+- Error taxonomy: different codes/messages for unknown field vs unauthorized field reveal existence
+- __typename sprinkling on edges to confirm types without schema
+</introspection_bypass>
+
+<defer_and_stream>
+- Use @defer and @stream to obtain partial results or subtrees hidden by parent checks; confirm server supports incremental delivery
+{% raw %}
+query @defer {
+  me { id }
+  ... @defer { adminPanel { secrets } }
+}
+{% endraw %}
+</defer_and_stream>
+
+<fragment_and_complexity_bombs>
+- Recursive fragment spreads and wide selection sets cause CPU/memory spikes; craft minimal reproducible bombs to validate cost limits
+{% raw %}
+fragment x on User { friends { ...x } }
+query { me { ...x } }
+{% endraw %}
+- Validate depth/complexity limiting, query cost analyzers, and timeouts
+</fragment_and_complexity_bombs>
+
+<federation>
+- Apollo Federation: query _service { sdl } if exposed; target _entities to materialize foreign objects by key without proper auth in subgraphs
+{% raw %}
+query {
+  _entities(representations:[
+    {__typename:"User", id:"TARGET"}
+  ]) { ... on User { email roles } }
+}
+{% endraw %}
+- Look for auth done at gateway but skipped in subgraph resolvers; cross-subgraph IDOR via inconsistent ownership checks
+</federation>
+
+<subscriptions>
+- Check message-level authorization, not only handshake; attempt to subscribe to channels for other users/tenants; test cross-tenant event leakage
+- Abuse filter args in subscription resolvers to reference foreign IDs
+</subscriptions>
+
+<persisted_queries>
+- APQ hashes can be guessed/bruteforced or leaked from clients; replay privileged operations by supplying known hashes with attacker variables
+- Validate that hash→operation mapping enforces principal and operation allowlists
+</persisted_queries>
+
+<csrf_and_cors>
+- If cookie-auth is used and GET is accepted, test CSRF on mutations via query parameters; verify SameSite and origin checks
+- Cross-origin GraphiQL/Playground exposure with credentials can leak data via postMessage bridges
+</csrf_and_cors>
+
+<waf_evasion>
+- Reshape queries: comments, block strings, Unicode escapes, alias/fragment indirection, JSON variables vs inline args, GET vs POST vs application/graphql
+- Split fields across fragments and inline spreads to avoid naive signatures
+</waf_evasion>
+</advanced_techniques>
+
+<bypass_techniques>
+<transport_and_parsers>
+- Toggle content-types: application/json, application/graphql, multipart/form-data; try GET with query and variables params
+- HTTP/2 multiplexing and connection reuse to widen timing windows and rate limits
+</transport_and_parsers>
+
+<naming_and_aliasing>
+- Case/underscore variations, Unicode homoglyphs (server-dependent), aliases masking sensitive field names
+</naming_and_aliasing>
+
+<gateway_and_cache>
+- CDN/key confusion: responses cached without considering Authorization or variables; manipulate Vary and Accept headers
+- Redirects and 304/206 behaviors leaking partially cached GraphQL responses
+</gateway_and_cache>
+</bypass_techniques>
+
+<special_contexts>
+<relay>
+- node(id:…) global resolution: decode base64, swap type/id pairs, ensure per-type authorization is enforced inside resolvers
+- Connections: verify that filters (owner/tenant) apply before pagination; cursor tampering should not cross ownership boundaries
+</relay>
+
+<server_plugins>
+- Custom directives (@auth, @private) and plugins often annotate intent but do not enforce; verify actual checks in each resolver path
+</server_plugins>
+</special_contexts>
+
+<chaining_attacks>
+- GraphQL + IDOR: enumerate IDs via list fields, then fetch or mutate foreign objects
+- GraphQL + CSRF: trigger mutations cross-origin when cookies/auth are accepted without proper checks
+- GraphQL + SSRF: resolvers that fetch URLs (webhooks, metadata) abused to reach internal services
+</chaining_attacks>
+
+<validation>
+1. Provide paired requests (owner vs non-owner) differing only in identifiers/roles that demonstrate unauthorized access or mutation.
+2. Prove resolver-level bypass: show top-level checks present but child field/edge exposes data.
+3. Demonstrate transport parity: reproduce via HTTP and WS (subscriptions) or via persisted queries.
+4. Minimize payloads; document exact selection sets and variable shapes used.
+</validation>
+
+<false_positives>
+- Introspection available only on non-production/stub endpoints
+- Public fields by design with documented scopes
+- Aggregations or counts without sensitive attributes
+- Properly enforced depth/complexity and per-resolver authorization across transports
+</false_positives>
+
+<impact>
+- Cross-account/tenant data exposure and unauthorized state changes
+- Bypass of federation boundaries enabling lateral access across services
+- Credential/session leakage via lax CORS/CSRF around GraphiQL/Playground
+</impact>
+
+<pro_tips>
+1. Always diff the same operation under multiple principals with aliases in one request.
+2. Sprinkle __typename to map types quickly when schema is hidden.
+3. Attack edges: child resolvers often skip auth compared to parents.
+4. Try @defer/@stream and subscriptions to slip gated data in incremental events.
+5. Decode cursors and node IDs; assume base64 unless proven otherwise.
+6. Federation: exercise _entities with crafted representations; subgraphs frequently trust gateway auth.
+7. Persisted queries: extract hashes from clients; replay with attacker variables.
+8. Keep payloads small and structured; restructure rather than enlarge to evade WAFs.
+9. Validate defenses by code/config review where possible; don’t trust directives alone.
+10. Prove impact with role-separated, transport-separated, minimal PoCs.
+</pro_tips>
+
+<remember>GraphQL security is resolver security. If any resolver on the path to a field fails to bind subject, object, and action, the graph leaks. Validate every path, every transport, every environment.</remember>
+</graphql_protocol_guide>

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>