Authorization Logic Flaw Detection Prompt

This prompt is designed for security engineers, DevSecOps teams, and technical reviewers who need to systematically analyze access control code for authorization logic flaws. The primary job-to-be-done is identifying missing authorization checks, privilege escalation paths, and object-level permission bypasses before they reach production. It fits into pre-merge CI/CD gates, manual code review workflows, and security audit preparation. The ideal user has access to code context that includes authentication and authorization logic, user role definitions, and resource access patterns—this is not a black-box testing tool, but a white-box analysis aid that requires source code visibility to be effective.

To use this prompt effectively, you must provide concrete code context: the authorization middleware or decorators, role-checking functions, resource ownership verification logic, and any route handlers or API endpoints that enforce access control. The prompt expects [INPUT] to contain the relevant code sections, [CONTEXT] to describe the application's role model and permission structure, and [CONSTRAINTS] to specify the authorization framework in use (e.g., RBAC, ABAC, ReBAC). Without this context, the model cannot distinguish between intentional design choices and actual flaws. The output is structured findings mapped to specific code paths with exploit scenarios, making it suitable for integration into vulnerability management workflows where findings need to be tracked, prioritized, and remediated.

Do not use this prompt as a replacement for penetration testing, dynamic analysis, or a full threat model. It will not catch runtime configuration errors, infrastructure-level IAM misconfigurations, or authorization flaws that span multiple services without code visibility. It is also not suitable for analyzing compiled binaries, obfuscated code, or systems where the authorization logic is split across API gateways and external policy engines without providing that context. For high-risk applications handling financial transactions, healthcare data, or personally identifiable information, always pair automated detection with manual security review and consider supplementing with dynamic authorization testing tools that exercise the running system. The prompt is a focused detection tool—use it early and often in the development lifecycle, but never as the sole gate for authorization correctness.

This prompt template is designed to be pasted directly into your LLM interface. It instructs the model to act as a security reviewer specializing in authorization logic. The prompt is structured to accept a specific code block, the application's intended permission model, and a risk tolerance level. Before executing, you must replace every square-bracket placeholder with concrete values. The quality of the output depends heavily on the clarity of the [INTENDED_PERMISSION_MODEL]; vague role descriptions will produce vague or noisy findings.

textCopy
You are a principal security engineer reviewing code for authorization logic flaws. Your task is to analyze the provided code for missing authorization checks, privilege escalation paths, insecure direct object references (IDOR), and function-level access control bypasses.

## Input Code
[CODE_BLOCK]

## Intended Permission Model
[INTENDED_PERMISSION_MODEL]

## Constraints
- Map every finding to a specific line number or code block in [CODE_BLOCK].
- For each finding, provide a step-by-step exploit scenario that a malicious actor could use.
- Classify each finding using the [OUTPUT_SCHEMA] below.
- If no flaws are found, state "NO_AUTHZ_FLAWS_DETECTED" and explain why the code appears consistent with the intended permission model.
- Do not report non-authorization issues (e.g., XSS, SQL injection) unless they directly enable an authorization bypass.
- Adhere strictly to the [RISK_LEVEL] for your analysis depth.

## Output Schema
Return a valid JSON object with the following structure:
{
  "analysis_summary": "A concise summary of the overall authorization posture.",
  "findings": [
    {
      "finding_id": "AUTHZ-001",
      "title": "Short, descriptive title.",
      "cwe_id": "CWE-xxx",
      "severity": "CRITICAL|HIGH|MEDIUM|LOW|INFO",
      "location": "file.ext:line_start-line_end",
      "description": "Detailed explanation of the flaw.",
      "exploit_scenario": "Step-by-step reproduction steps.",
      "remediation": "Specific code or architectural change to fix the flaw.",
      "confidence": "HIGH|MEDIUM|LOW"
    }
  ]
}

## Risk Level
[RISK_LEVEL]

To adapt this template, start by replacing [CODE_BLOCK] with the actual code under review. The [INTENDED_PERMISSION_MODEL] is the most critical input; describe it precisely, for example: "Only users with the 'admin' role can access endpoints under /admin/*. Users can only access their own profile data, identified by a UUID in the JWT 'sub' claim matching the 'user_id' path parameter." For [RISK_LEVEL], use 'HIGH' for financial or authentication flows to force a more skeptical analysis, or 'STANDARD' for general application code. After receiving the output, always validate the JSON structure and manually verify at least the CRITICAL and HIGH severity findings against the source code. This prompt is a diagnostic tool, not a replacement for a full manual penetration test or a peer-reviewed security architecture review.

Integrating this prompt into a security review pipeline requires treating it as a specialized static analysis step that operates on code diffs or full file content. The prompt is designed to receive a [CODE_DIFF] or [FULL_FILE] input alongside an [APPLICATION_CONTEXT] that describes the user roles, permission model, and trust boundaries. In a CI/CD environment, trigger this analysis on pull requests that touch authorization middleware, access control decorators, route handlers with role checks, or data access layers. The model should be instructed to output a structured JSON array of findings, each with a code_location, vulnerability_type, exploit_scenario, severity, and confidence score. This structured output is critical for downstream automated processing.

To build a reliable harness, wrap the model call in a validation layer that checks the output schema before accepting results. Use a JSON Schema validator to ensure every finding object has the required fields and that severity is one of a predefined set (e.g., CRITICAL, HIGH, MEDIUM, LOW). Implement a retry strategy with a maximum of 2 additional attempts if validation fails, feeding the validation errors back into the prompt as [PREVIOUS_ERRORS] so the model can self-correct. Log every attempt, the raw output, and the validation result to an audit trail. For high-risk repositories, configure the system to automatically request human review for any finding with a severity of CRITICAL or HIGH by creating a ticket in your vulnerability management system (e.g., Jira, DefectDojo) and blocking the PR merge until a security engineer acknowledges the finding. Choose a model with strong code reasoning capabilities; GPT-4o or Claude 3.5 Sonnet are appropriate starting points. Avoid using smaller, faster models for this task as the cost of a missed authorization flaw is far higher than the inference cost.

Before deploying, build an evaluation harness using a golden dataset of code samples with seeded authorization flaws (e.g., missing ownership checks, unvalidated role parameters, direct object references). Measure both recall (did it catch the seeded flaws?) and precision (did it flag safe code?). Track false negatives closely, as a missed CRITICAL finding is the primary failure mode. In production, monitor the rate of findings per PR and the distribution of severity levels to detect drift. If the model suddenly starts flagging every PR with HIGH severity findings, it may indicate prompt injection or a regression in model behavior. Finally, never treat the model's output as the final word; always route findings into your existing vulnerability management workflow where a human can verify exploitability and approve the remediation path.