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

strix/prompts/frameworks/nextjs.jinja

@@ -0,0 +1,126 @@
+<nextjs_security_testing_guide>
+<title>NEXT.JS — ADVERSARIAL TESTING PLAYBOOK</title>
+
+<critical>Modern Next.js combines multiple execution contexts (Edge, Node, RSC, client) with smart caching (ISR/RSC fetch cache), middleware, and server actions. Authorization and cache boundaries must be enforced consistently across all paths or attackers will cross tenants, leak data, or invoke privileged actions.</critical>
+
+<surface_map>
+- Routers: App Router (`app/`) and Pages Router (`pages/`) coexist; test both
+- Runtimes: Node.js vs Edge (V8 isolates with restricted APIs)
+- Data paths: RSC (server components), Client components, Route Handlers (`app/api/**`), API routes (`pages/api/**`)
+- Middleware: `middleware.ts`/`_middleware.ts`
+- Rendering modes: SSR, SSG, ISR, on-demand revalidation, draft/preview mode
+- Images: `next/image` optimization and remote loader
+- Auth: NextAuth.js (callbacks, CSRF/state, callbackUrl), custom JWT/session bridges
+- Server Actions: streamed POST with `Next-Action` header and action IDs
+</surface_map>
+
+<methodology>
+1. Inventory routes (pages + app), static vs dynamic segments, and params. Map middleware coverage and runtime per path.
+2. Capture baseline for each role (unauth, user, admin) across SSR, API routes, Route Handlers, Server Actions, and streaming data.
+3. Diff responses while toggling runtime (Edge/Node), content-type, fetch cache directives, and preview/draft mode.
+4. Probe caching and revalidation boundaries (ISR, RSC fetch, CDN) for cross-user/tenant leaks.
+</methodology>
+
+<high_value_targets>
+- Middleware-protected routes (auth, geo, A/B)
+- Admin/staff paths, draft/preview content, on-demand revalidate endpoints
+- RSC payloads and flight data, streamed responses (server actions)
+- Image optimizer and custom loaders, remotePatterns/domains
+- NextAuth callbacks (`/api/auth/callback/*`), sign-in providers, CSRF/state handling
+- Edge-only features (bot protection, IP gates) and their Node equivalents
+</high_value_targets>
+
+<advanced_techniques>
+<middleware_bypass>
+- Test for CVE-class middleware bypass via `x-middleware-subrequest` crafting and `x-nextjs-data` probing. Look for 307 + `x-middleware-rewrite`/`x-nextjs-redirect` headers and attempt bypass on protected routes.
+- Attempt direct route access on Node vs Edge runtimes; confirm protection parity.
+</middleware_bypass>
+
+<server_actions>
+- Capture streamed POSTs containing `Next-Action` headers. Map hashed action IDs via source maps or specialized tooling to discover hidden actions.
+- Invoke actions out of UI flow and with alternate content-types; verify server-side authorization is enforced per action and not assumed from client state.
+- Try cross-tenant/object references within action payloads to expose BOLA/IDOR via server actions.
+</server_actions>
+
+<rsc_and_cache>
+- RSC fetch cache: probe `fetch` cache modes (force-cache, default, no-store) and revalidate tags/paths. Look for user-bound data cached without identity keys (ETag/Set-Cookie unaware).
+- Confirm that personalized data is rendered via `no-store` or properly keyed; attempt cross-user content via shared caches/CDN.
+- Inspect Flight data streams for serialized sensitive fields leaking through props.
+</rsc_and_cache>
+
+<isr_and_revalidation>
+- Identify ISR pages (stale-while-revalidate). Check if responses may include user-bound fragments or tenant-dependent content.
+- On-demand revalidation endpoints: look for weak secrets in URLs, referer-disclosed tokens, or unvalidated hosts triggering `revalidatePath`/`revalidateTag`.
+- Attempt header-smuggling or method variations to trigger revalidation flows.
+</isr_and_revalidation>
+
+<draft_preview_mode>
+- Draft/preview mode toggles via secret URLs/cookies; search for preview enable endpoints and secrets in client bundles/env leaks.
+- Try setting preview cookies from subdomains, alternate paths, or through open redirects; observe content differences and persistence.
+</draft_preview_mode>
+
+<next_image_ssrf>
+- Review `images.domains`/`remotePatterns` in `next.config.js`; test SSRF to internal hosts (IPv4/IPv6 variants, DNS rebinding) if patterns are broad.
+- Custom loader functions may fetch with arbitrary URLs; test protocol smuggling and redirection chains.
+- Attempt cache poisoning: craft same URL with different normalization to affect other users.
+</next_image_ssrf>
+
+<nextauth_pitfalls>
+- State/nonce/PKCE: validate per-provider correctness; attempt missing/relaxed checks leading to login CSRF or token mix-up.
+- Callback URL restrictions: open redirect in `callbackUrl` or mis-scoped allowed hosts; hijack sessions by forcing callbacks.
+- JWT/session bridges: audience/issuer not enforced across API routes/Route Handlers; attempt cross-service token reuse.
+</nextauth_pitfalls>
+
+<edge_runtime_diffs>
+- Edge runtime lacks certain Node APIs; defenses relying on Node-only modules may be skipped. Compare behavior of the same route in Edge vs Node.
+- Header trust and IP determination can differ at the edge; test auth decisions tied to `x-forwarded-*` variance.
+</edge_runtime_diffs>
+
+<client_and_dom>
+- Identify `dangerouslySetInnerHTML`, Markdown renderers, and user-controlled href/src attributes. Validate CSP/Trusted Types coverage for SSR/CSR/hydration.
+- Attack hydration boundaries: server vs client render mismatches can enable gadget-based XSS.
+</client_and_dom>
+</advanced_techniques>
+
+<bypass_techniques>
+- Content-type switching: `application/json` ↔ `multipart/form-data` ↔ `application/x-www-form-urlencoded` to traverse alternate code paths.
+- Method override/tunneling: `_method`, `X-HTTP-Method-Override`, GET on endpoints unexpectedly accepting writes.
+- Case/param aliasing and query duplication affecting middleware vs handler parsing.
+- Cache key confusion at CDN/proxy (lack of Vary on auth cookies/headers) to leak personalized SSR/ISR content.
+</bypass_techniques>
+
+<special_contexts>
+<uploads_and_files>
+- API routes and Route Handlers handling file uploads: check MIME sniffing, Content-Disposition, stored path traversal, and public serving of user files.
+- Validate signing/scoping of any generated file URLs (short TTL, audience-bound).
+</uploads_and_files>
+
+<integrations_and_webhooks>
+- Webhooks that trigger revalidation/imports: require HMAC verification; test with replay and cross-tenant object IDs.
+- Analytics/AB testing flags controlled via cookies/headers; ensure they do not unlock privileged server paths.
+</integrations_and_webhooks>
+</special_contexts>
+
+<validation>
+1. Provide side-by-side requests for different principals showing cross-user/tenant content or actions.
+2. Prove cache boundary failure (RSC/ISR/CDN) with response diffs or ETag collisions.
+3. Demonstrate server action invocation outside UI with insufficient authorization checks.
+4. Show middleware bypass (where applicable) with explicit headers and resulting protected content.
+5. Include runtime parity checks (Edge vs Node) proving inconsistent enforcement.
+</validation>
+
+<pro_tips>
+1. Enumerate with both App and Pages routers: many apps ship a hybrid surface.
+2. Treat caching as an identity boundary—test with cookies stripped, altered, and with Vary/ETag diffs.
+3. Decode client bundles for preview/revalidate secrets, action IDs, and hidden routes.
+4. Use streaming-aware tooling to capture server actions and RSC payloads; diff flight data.
+5. For NextAuth, fuzz provider params (state, nonce, scope, callbackUrl) and verify strictness.
+6. Always retest under Edge and Node; misconfigurations often exist in only one runtime.
+7. Probe `next/image` aggressively but safely—test IPv6/obscure encodings and redirect behavior.
+8. Validate negative paths: other-user IDs, other-tenant headers/subdomains, lower roles.
+9. Focus on export/report/download endpoints; they often bypass resolver-level checks.
+10. Document minimal, reproducible PoCs; avoid noisy payloads—prefer precise diffs.
+</pro_tips>
+
+<remember>Next.js security breaks where identity, authorization, and caching diverge across routers, runtimes, and data paths. Bind subject, action, and object on every path, and key caches to identity and tenant explicitly.</remember>
+</nextjs_security_testing_guide>

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>