Authentication and Authorization Test Prompt

This prompt is designed for security engineers and QA leads who need to validate access control implementations before they ship. It takes an authorization model definition, role hierarchy, and endpoint inventory as input, then produces a structured test matrix covering role-based access, token validation, session management, and privilege escalation attempts. The primary job-to-be-done is systematic coverage: ensuring every role, resource, and action combination is evaluated against the intended permission model, not just the happy path.

Use this prompt when you have a defined permission model and need to generate a comprehensive test plan. Required context includes a formal role hierarchy (e.g., admin, editor, viewer), a resource-to-action mapping (e.g., GET /api/documents, DELETE /api/users), and any token or session lifecycle rules. The prompt works best when fed structured definitions—YAML or JSON representations of your authorization model—rather than prose descriptions. Do not use this prompt for runtime penetration testing or live system exploitation. It generates test plans, not attack payloads. It will not execute requests, analyze live traffic, or validate actual token signatures.

Before running this prompt, ensure you have completed the authorization design and documented it in a machine-readable format. The output is a test matrix, not a replacement for dynamic analysis tools like OWASP ZAP or Burp Suite. After generating the matrix, you should review it for completeness against your threat model, then wire the test cases into your CI pipeline or manual QA runbook. Avoid using this prompt for systems where the permission model is implicit or undocumented—the output quality degrades sharply without structured input.

This prompt template is designed to be pasted directly into your AI coding agent or test generation pipeline. It instructs the model to analyze authentication and authorization logic—whether expressed in code, configuration, or specification—and produce a structured test matrix covering role-based access, token validation, session management, and privilege escalation attempts. The placeholders allow you to adapt the prompt to your specific codebase, identity provider, and risk profile without rewriting the core instruction.

textCopy
You are a security test engineer reviewing an authentication and authorization implementation. Your task is to generate a comprehensive test matrix that validates access control correctness, session integrity, and resistance to common privilege escalation vectors.

## INPUT
Source code, configuration, or specification to analyze:

[INPUT]

codeCopy

## CONTEXT
- Identity provider: [IDP_TYPE] (e.g., Auth0, Okta, Cognito, custom JWT issuer)
- Token format: [TOKEN_FORMAT] (e.g., JWT with RS256, opaque token, session cookie)
- Role definitions and permission mappings: [ROLE_DEFINITIONS]
- Session management approach: [SESSION_MANAGEMENT] (e.g., stateless JWT, server-side sessions, refresh token rotation)
- Multi-tenancy model (if applicable): [TENANCY_MODEL]
- Relevant compliance requirements: [COMPLIANCE_REQUIREMENTS] (e.g., SOC2, HIPAA, PCI-DSS)

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "test_matrix": [
    {
      "test_id": "AUTH-001",
      "category": "authentication | authorization | session | token | privilege_escalation",
      "scenario": "Human-readable description of what is being tested",
      "preconditions": ["List of required state before test execution"],
      "action": "The specific request, call, or operation to perform",
      "expected_result": "The expected outcome including HTTP status, error codes, or behavior",
      "risk_level": "critical | high | medium | low",
      "test_type": "unit | integration | manual | automated",
      "references": ["Links to relevant code, config, or spec sections"]
    }
  ],
  "coverage_summary": {
    "total_tests": 0,
    "by_category": {},
    "by_risk_level": {},
    "uncovered_scenarios": ["List of scenarios not covered by current implementation"]
  },
  "privilege_escalation_vectors": [
    {
      "vector": "Description of potential escalation path",
      "severity": "critical | high | medium | low",
      "current_mitigation": "How the implementation currently handles this",
      "recommended_test": "Test ID that validates this vector"
    }
  ]
}

## CONSTRAINTS
- Generate tests for every role and permission combination defined in [ROLE_DEFINITIONS]
- Include negative test cases: expired tokens, malformed tokens, missing scopes, wrong audience, tampered claims
- Cover token refresh, revocation, and rotation scenarios
- Test cross-tenant access attempts if [TENANCY_MODEL] is present
- Include session fixation, session hijacking, and concurrent session tests
- Verify that authorization decisions are enforced at the appropriate layer (middleware, service, data access)
- Flag any authorization checks that appear to be client-side only
- For each test, specify whether it requires automated or manual execution

## EXAMPLES
Example test case:
{
  "test_id": "AUTH-042",
  "category": "authorization",
  "scenario": "User with 'viewer' role attempts to access admin-only endpoint",
  "preconditions": ["Valid JWT for user with role=viewer", "Admin endpoint /api/admin/users is deployed"],
  "action": "GET /api/admin/users with viewer JWT in Authorization header",
  "expected_result": "HTTP 403 Forbidden with error code 'insufficient_permissions'",
  "risk_level": "high",
  "test_type": "automated",
  "references": ["src/middleware/authz.ts:45-78", "src/routes/admin.ts:12"]
}

## RISK_LEVEL
[RISK_LEVEL] (Use 'high' for production authentication systems, 'medium' for internal tools, 'low' for development environments)

After pasting this template, replace each square-bracket placeholder with your actual implementation details. The [INPUT] placeholder should contain the source code, configuration files, or specification documents you want analyzed. For large codebases, consider providing focused excerpts—middleware, guards, decorators, and policy definitions—rather than entire repositories. The [ROLE_DEFINITIONS] placeholder is critical: include a complete mapping of roles to permissions, as gaps here produce incomplete test matrices. If your system uses attribute-based access control (ABAC) rather than role-based (RBAC), adapt the [ROLE_DEFINITIONS] to describe your attribute policies instead. Before running the generated tests, validate the output against your existing test patterns and ensure the test IDs and references map to real code paths.

This prompt is designed to operate as a security analysis tool, not a live decision-maker. It should be integrated into a CI/CD pipeline or a scheduled security review job, never exposed directly to end users. The harness must enforce strict input validation on the [POLICY_DOCUMENT] and [CODE_CONTEXT] fields, ensuring they are sourced from a trusted, version-controlled repository and not from arbitrary user input. The model's output is a structured test matrix, which must be parsed and validated before any test code is generated or executed.

The implementation should follow a validate → generate → review → execute loop. First, validate that the input policy document is parseable and the code context is scoped to the relevant authorization logic. After the model returns the test matrix, a post-processing validator must check that every role, permission, and resource from the policy is covered by at least one test case. Any missing coverage should trigger a retry with a more specific prompt, such as 'Add test cases for the [MISSING_ROLE] role on the [MISSING_RESOURCE] resource.' The generated test cases should be written to a temporary file and flagged for human review before being committed to the test suite. For high-risk systems, require an explicit approval step in the CI pipeline.

Log every interaction for auditability: the prompt version, the input hashes, the raw model output, the validation results, and the reviewer's decision. Use a structured logging format that ties each test case back to the specific policy rule it verifies. Avoid wiring this prompt directly to a test runner without human review, as the model may misinterpret policy nuances or generate tests that pass but don't actually verify the intended security property. The primary failure mode is a false sense of security from incomplete coverage, so the harness must treat the model's output as a draft requiring expert validation.