Debugging
AuraScore 81/100

Cross-Engagement Data Leakage and RBAC Failure Audit Checklist

Comprehensive verification checklist for diagnosing authorization bypasses and tenant boundary leaks across consulting portal APIs.

Use this prompt when client confidentiality boundaries are compromised or ABAC token evaluations return improper engagement permissions. It provides a structured fault-tree checklist to isolate token claims, query filters, and cache poisoning.

Template

Role: Staff Application Security Architect specializing in multi-tenant professional services portals.

Context

  • Multi-tenancy paradigm: {{tenant_architecture}}
  • Identity & Access Provider: {{auth_provider}}
  • Vulnerable service/route: {{compromised_endpoint}}
  • Manifested authorization flaw: {{observed_scope_leak}}
  • Session & Token Cache: {{session_caching_layer}}
  • Governance & Compliance constraint: {{target_compliance_standard}}

Task

Generate a rigorous, security-focused debugging checklist to isolate the authorization bypass in {{compromised_endpoint}}, determine whether token spoofing or cache poisoning is occurring, and verify fix integrity.

Method

  1. Structure verification steps for incoming JWT/OIDC claim validation and signing key rotation handling within {{auth_provider}}.
  2. Formulate checks to trace token serialization, cache key composition, and TTL invalidation bugs in {{session_caching_layer}}.
  3. Audit the database layer data filter predicates according to {{tenant_architecture}} to determine if dynamic WHERE clauses or Row Level Security policies were bypassed.
  4. Design boundary tests for {{compromised_endpoint}} specifically targeting object-level authorization (BOLA/IDOR) and {{observed_scope_leak}}.
  5. Verify that contextual engagement scopes (e.g., project-based role assignments) do not bleed across client tenants in thread locals or shared connection pools.
  6. Define forensic log audit checks to identify the blast radius and determine all tenant IDs impacted under {{target_compliance_standard}} rules.
  7. Provide post-patch regression assertions to ensure authorization checks execute synchronously before data serialization.

Constraints

  • MUST write actionable diagnostic steps that an AppSec engineer can execute immediately in staging and production logs.
  • MUST NOT expose raw client PII or unredacted token signatures in diagnostic outputs.
  • Every check MUST categorize severity based on CVSS scoring methodology.
  • Include explicit commands or assertion logic for API gateway policy validation.

Output format

Provide a technical checklist structured into 4 sequential domains: 1. Token & Identity Assertion Verification, 2. Middleware & Cache Boundary Audit, 3. Data Layer Tenancy Isolation Checks, and 4. Forensic Exposure Assessment. Format items as [ ] [Control ID] [Item Title]: [Validation Step] | Expected Result: [Strict Condition] | Severity: [Critical/High/Medium].

Self-review

  • Verify inclusion of {{tenant_architecture}}, {{auth_provider}}, {{compromised_endpoint}}, {{observed_scope_leak}}, {{session_caching_layer}}, and {{target_compliance_standard}}.
  • Confirm that checklist items target both code-level authorization logic and caching layer bugs.
  • Ensure output strictly matches the specified Markdown checkbox structure.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-debugging
professional-services
security
rbac
multi-tenancy