API Threat Modeling Prompt Template

This prompt is designed for security engineers and architects who need a structured, design-phase threat enumeration against a stable API contract. The primary job-to-be-done is accelerating the initial threat identification step so that human reviewers can focus on impact analysis and mitigation design, rather than starting from a blank page. The ideal user has an OpenAPI specification that is complete enough to review, a defined data classification for the resources involved, and a clear deployment context (e.g., public-facing, internal, partner-facing). Use this prompt when the contract is still cheap to change—before implementation begins—so that findings can be addressed in the design rather than patched after deployment.

This prompt is not a replacement for a full STRIDE, PASTA, or attack-tree workshop. It does not perform runtime analysis, penetration testing, or dynamic scanning. It will not identify threats that require deep business logic understanding beyond what is expressed in the API contract. Do not use this prompt as a compliance artifact on its own; the output should be treated as a structured starting point for human-led threat modeling sessions. The prompt requires three concrete inputs: an OpenAPI specification (as raw text or structured JSON), a data classification label (e.g., PII, PCI, internal-only, public), and a deployment context description. Without these, the threat enumeration will be generic and less actionable.

After running this prompt, the output should be reviewed by a security engineer or architect who can validate the threat categories, assess impact levels, and design mitigations. The prompt covers six core threat categories—authentication bypass, authorization flaws, data exposure, injection, rate-limit abuse, and enumeration risks—but it may miss threats specific to your business logic or infrastructure. Always pair this prompt with a human review step, and consider feeding the output into a formal threat modeling session for deeper analysis. If your API handles regulated data (e.g., healthcare, financial), ensure that a qualified security reviewer signs off on the findings before implementation proceeds.

This prompt template is designed to be pasted directly into your AI workspace. It instructs the model to act as a security architect and produce a structured threat enumeration for a given API contract. The output is organized by threat category—auth bypass, data exposure, injection, rate-limit abuse, and enumeration—and includes severity, exploitability, and mitigation guidance. Before using this prompt, ensure you have your API specification (preferably an OpenAPI document) and a clear description of your deployment context, including network boundaries, authentication mechanisms, and data classification levels.

textCopy
You are a senior application security architect performing a design-level threat model on an API contract. Your analysis must be structured, evidence-based, and actionable. Do not invent threats that are not plausible given the provided context.

## API Specification
[API_SPEC]

## Deployment Context
- Network Exposure: [NETWORK_EXPOSURE: internal/partner/public]
- Authentication Mechanism: [AUTH_MECHANISM: e.g., OAuth2 with JWT, API Keys, mTLS]
- Data Classification: [DATA_CLASSIFICATION: public/internal/confidential/restricted]
- Rate Limiting in Place: [RATE_LIMITING: yes/no/partial]
- Consumer Types: [CONSUMER_TYPES: e.g., web app, mobile app, third-party, internal service]

## Output Schema
Produce a JSON object with a "threat_model" array. Each object in the array must have the following fields:
- "threat_id": A unique identifier string (e.g., "TM-001").
- "category": One of ["auth_bypass", "data_exposure", "injection", "rate_limit_abuse", "enumeration"].
- "affected_endpoint": The HTTP method and path from the spec.
- "description": A clear, one-sentence description of the threat.
- "exploitability": One of ["low", "medium", "high", "critical"].
- "impact": One of ["low", "medium", "high", "critical"].
- "mitigation": A concise, actionable recommendation.
- "requires_human_review": A boolean. Set to true if the threat involves complex business logic, regulatory risk, or architectural trade-offs that an automated system cannot fully assess.

## Constraints
- Base every threat on a specific endpoint, parameter, or data flow visible in the API specification.
- If the specification is incomplete or missing critical security details (e.g., no auth scheme defined), add a "precondition" note at the top of your response.
- Do not include generic infrastructure threats (e.g., DDoS on the load balancer) unless they are directly exploitable via the API's design.
- Prioritize threats that could lead to data breaches, privilege escalation, or service disruption.

To adapt this template, replace the square-bracket placeholders with your specific context. The [API_SPEC] placeholder should contain the full text of your OpenAPI document or a detailed summary of your endpoints, request bodies, and parameters. The deployment context variables are critical for the model to calibrate exploitability and impact; for example, an enumeration risk on a public API is far more severe than on an internal service with mutual TLS. After receiving the output, validate the JSON structure programmatically before ingestion. For high-risk APIs handling restricted data, every threat marked with requires_human_review: true must be triaged by a security engineer before the model's output is considered final. Do not use this prompt as a substitute for a formal threat modeling exercise like STRIDE or PASTA; it is a design-time accelerator, not a compliance artifact.

This prompt is designed for a human-in-the-loop security review workflow, not for fully autonomous threat detection. The primary integration point is a security review tool, CI/CD pipeline gate, or internal developer portal where an API specification (OpenAPI, GraphQL schema, or gRPC proto) is submitted. The application layer should handle spec parsing and normalization before the prompt is ever called, ensuring the model receives a clean, structured representation of the API contract rather than raw, potentially malformed files.

Input preparation is the most critical harness component. Before calling the LLM, your application must extract and normalize the following from the submitted spec: all endpoint paths and HTTP methods, authentication schemes per endpoint, request/response schemas with field-level types and descriptions, error response definitions, and any rate-limiting or pagination metadata. This normalized context is what populates the [API_SPEC_CONTEXT] placeholder. Do not pass raw YAML or JSON to the model; pre-process it into a concise, deterministic summary to reduce token waste and prevent the model from hallucinating about spec contents it misparsed.

Output validation must run after every model response. Parse the JSON output and verify that each threat entry contains the required fields: threat_id, category, affected_endpoint, risk_severity, precondition, impact, and mitigation. Reject any response where more than one threat entry is missing a required field, and retry with a stricter schema reminder. For high-risk APIs (auth services, payment endpoints, PII processors), flag any CRITICAL severity finding for mandatory human review before the workflow can be marked complete. Log every prompt invocation, the spec hash, the model version, and the validator pass/fail status for auditability.

Model choice and retries matter here. Use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) because threat enumeration requires causal reasoning about attack chains, not pattern matching. Set temperature=0.2 or lower to reduce variance in threat coverage. If the output fails validation, retry once with the validation errors appended to the prompt as [PREVIOUS_OUTPUT_ERRORS]. If the second attempt also fails, surface the partial output to a human reviewer with a clear warning that automated validation failed. Never silently discard a failed threat model.

Tool integration can strengthen this workflow. If your organization maintains a threat library or past security review database, use retrieval-augmented generation (RAG) to inject relevant historical threats into the [REFERENCE_THREATS] placeholder. This grounds the model in your specific attack surface history. Additionally, wire the validated output into your ticketing system: each HIGH or CRITICAL finding should auto-create a security review task with the threat details, affected endpoint, and suggested mitigation attached. This closes the loop between design-time threat modeling and remediation tracking.