Security Threat Guide

security-threat-guide

Purpose

Map attack surfaces and ask probing questions that guide the human to identify threats themselves — never write patches, exploits, or security controls; never produce a vulnerability list on the human's behalf.

Hard Refusals

• Never write a patch or fix — not even "you should add input validation here." Prescribing a fix is doing the security work for the human.
• Never write or describe an exploit — even "an attacker could do X by sending Y" as a demonstration crosses into producing attack tooling.
• Never produce a completed threat model — the human must build the threat model; the AI asks the questions that populate it.
• Never say "this is secure" — security is not a binary state and approval without full context is misleading.
• Never skip a threat category because the human says it doesn't apply — make the human confirm why it doesn't apply.

Triggers

• "Is this secure?"
• "What are the security concerns with this design?"
• "How could this be attacked?"
• "I want to do a threat model for [system/feature]"
• "What should I be worried about security-wise?"

Workflow

1. Define the trust boundary

Before threat analysis, the human must describe what the system trusts and what it doesn't.

Gate 1: Human has described the trust boundary, input sources, and access surface. Do not begin threat questioning without these.

Memory note: Record the trust boundary description in SKILL_MEMORY.md.

2. Walk the STRIDE categories

For each STRIDE category, ask one question that makes the human think about it for their specific system. Do not explain what STRIDE is — apply it.

Ask one category at a time. Wait for the human's response before moving to the next.

Gate 2: Human has engaged with all six categories — answered, flagged as not applicable with reasoning, or identified as needing investigation.

3. Probe the identified risks

For each threat the human identifies, ask the one question that most directly assesses severity or detectability:

Human names a threat?
├── "Under what conditions does this become exploitable?"
├── "What would an attacker need in order to exploit this?"
├── "If this were exploited, what's the worst case impact?"
└── "How would you know if this was being exploited right now?"

Gate 3: Every named threat has been assessed for conditions, attacker requirements, impact, and detectability.

4. Surface the unasked questions

After Gate 3, ask about threat categories the human may not have raised:

Gate 4: Human has addressed or explicitly scoped out each category in Gate 4.

5. Close with ownership

"You've walked through [N] threat categories and identified [M] specific risks.
For each risk, what's your decision — accept it, mitigate it, or investigate further?"

Do not suggest mitigations. The human must state the disposition for each named threat.

Deviation Protocol

If the human says "just tell me what the vulnerabilities are" or "what patch do I need?":

1. Acknowledge: "I can see the pressure to get to fixes — that's the natural instinct." 2. Assess: Ask "Which threat feels most urgent to you right now?" — focus the session on that single threat area. 3. Guide forward: Run the probing questions for that threat specifically. The goal is for the human to understand and own the threat, not receive a fix to paste in.

Related skills

• skills/core-inversions/code-review-challenger — when a security threat is found in existing code that needs review
• skills/cognitive-forcing/devils-advocate-mode — for sustained adversarial pressure on a security design decision
• skills/core-inversions/architect-interrogator — when security concerns reveal architectural decisions that need re-examination

Security Threat Guide — Extended Threat Reference

This file extends the STRIDE questions in the security-threat-guide workflow with a fuller threat pattern bank. Use this when the six STRIDE questions in SKILL.md are insufficient for the system being analyzed — specifically for web systems, APIs, cloud infrastructure, and authentication flows.

For each threat pattern: the detection signal, the concrete impact, and the single interrogation question most likely to surface it.

---

Authentication and Identity Threats

Credential Stuffing Surface

What it looks like: A login endpoint that accepts username/password with no rate limiting, no lockout, and no anomaly detection — making it a target for automated credential stuffing from leaked password databases.

Detection signal: Login endpoint with no rate limiting header, no CAPTCHA path, no failed-attempt tracking.

Impact: Attackers with a list of 1M leaked credentials can test all of them against your users automatically. Success rate is typically 0.1-2% — meaning hundreds to thousands of account takeovers.

Interrogation question: "What happens after 100 failed login attempts from the same IP in one minute? What happens after 100 failed attempts across 100 different IPs targeting the same account?"

---

Token Scope Excess

What it looks like: API tokens or OAuth scopes that grant more permissions than the use case requires — a token that can read and write when the integration only needs to read.

Detection signal: Tokens issued with broad scopes "for convenience." Service accounts with admin rights. API keys that aren't rotated and aren't scoped to a specific operation.

Impact: If the token is leaked, the attacker has access to everything the token can do — not just what the legitimate use case needed.

Interrogation question: "What is the minimum set of permissions this token needs to do its job? What can it do beyond that, and what is the risk if it is leaked?"

---

Session Fixation

What it looks like: A session ID that doesn't change on privilege escalation — the same session token is used before and after login, allowing an attacker who knows the pre-login token to take over the authenticated session.

Detection signal: Session tokens issued before authentication that persist through the login event.

Impact: An attacker who can set a victim's session token (e.g., via a link) can share the session after the victim authenticates.

Interrogation question: "When a user logs in, does their session token change? Is the pre-login token invalidated?"

---

JWT Insecurity

What it looks like: JWTs that are not validated correctly — accepting alg: none, not checking the signature, accepting expired tokens, or using a weak or shared secret.

Detection signal: JWT validation code that doesn't explicitly specify allowed algorithms. Secrets that are short, predictable, or shared across services.

Impact: An attacker can forge tokens, escalate privileges, or reuse expired tokens.

Interrogation question: "Where is the JWT signature validated? What happens if someone sends a token with alg: none? How long do tokens remain valid after issuance?"

---

Injection and Input Threats

SQL Injection Surface

What it looks like: User-controlled input interpolated into SQL queries — string concatenation, format strings, or ORM raw query escapes used without parameterization.

Detection signal: Query construction that involves string concatenation with any value that came from outside the system. raw(), execute(), or query() calls with user input.

Impact: An attacker can read any data in the database, modify records, delete tables, or execute OS commands if the database user has sufficient privilege.

Interrogation question: "For every query in this system that takes user input — is the input parameterized, or is it concatenated into the query string? Where is that enforced?"

---

Command Injection Surface

What it looks like: User-controlled input passed to a shell command, subprocess call, or system function — allowing an attacker to append shell metacharacters and run arbitrary commands.

Detection signal: exec(), system(), subprocess.run(shell=True), or equivalent with any string that includes user-provided data.

Impact: Full remote code execution on the server.

Interrogation question: "Does any user-supplied input ever reach a shell command, subprocess call, or eval? What's the worst case if that input contains ;, |, or backticks?"

---

Path Traversal

What it looks like: User-controlled input used to construct a file path — allowing an attacker to use ../ sequences to read or write files outside the intended directory.

Detection signal: File operations where the path includes any component derived from user input. Download or upload endpoints that accept filenames.

Impact: An attacker can read /etc/passwd, application secrets, private keys, or any file the process has access to.

Interrogation question: "Can a user control any part of a file path in this system? What happens if that input contains ../../etc/passwd?"

---

Template Injection

What it looks like: User-controlled input rendered by a template engine in a context where template syntax is evaluated — allowing an attacker to execute template expressions.

Detection signal: Template rendering where the template itself (not just the variables) can be influenced by user input. Email templates, report generators, or user-configurable output formats.

Impact: Depending on the engine, this can lead to remote code execution, server-side file reads, or environment variable exposure.

Interrogation question: "Can a user influence what gets passed to the template engine as a template string, as opposed to just the variables? What happens if they include {{ 7*7 }}?"

---

Authorization and Access Control Threats

IDOR (Insecure Direct Object Reference)

What it looks like: An API that accepts a resource ID and returns the resource without checking whether the requesting user is authorized to access that specific resource.

Detection signal: Endpoints like GET /orders/12345 or GET /users/67890/documents/1 where the ID is user-supplied and the only authorization check is "are you logged in?"

Impact: Any authenticated user can access any other user's data by enumerating or guessing IDs.

Interrogation question: "For every endpoint that takes a resource ID — does the authorization check verify that the requesting user owns or has permission to access that specific resource, not just that they are authenticated?"

---

Privilege Escalation via Mass Assignment

What it looks like: An API that binds request body fields directly to a model without an allowlist — allowing an attacker to set fields like role: admin or is_verified: true that were not intended to be user-settable.

Detection signal: ORM update() or create() calls that accept the entire request body without field filtering. Auto-binding frameworks without explicit field allowlists.

Impact: An attacker can set themselves as admin, verify their own account, or modify any field that exists on the model.

Interrogation question: "When a user submits data to update their profile or account — is there an explicit list of which fields they're allowed to set, or does the update accept any field that exists on the model?"

---

Broken Function Level Authorization

What it looks like: Admin or privileged endpoints that are protected only by convention (e.g., they're under /admin/) but have no actual authorization check on the server side.

Detection signal: Authorization checks that happen in middleware based on URL prefix, but individual endpoint handlers don't verify the caller's role. "Security through obscurity" for internal endpoints.

Impact: An attacker who discovers the endpoint URL can call it without having admin privileges.

Interrogation question: "For your admin or privileged endpoints — is authorization enforced in each handler, or is it enforced by a URL pattern? What happens if someone calls the handler with a non-admin token?"

---

Data Exposure Threats

Sensitive Data in Logs

What it looks like: Log statements that include passwords, tokens, PII, financial data, or health information — either because they were added for debugging and never removed, or because a catch-all logger serializes entire request objects.

Detection signal: Request logging middleware that logs headers (including Authorization). Error handlers that log the full exception including input data. Debug log statements that were never removed.

Impact: Logs are often stored less securely than databases, shared more broadly, and retained longer. A log breach exposes data that was never meant to be logged.

Interrogation question: "What does a log entry look like when a user logs in? When a payment is processed? Does it include the password, token, card number, or any PII?"

---

API Over-exposure

What it looks like: An API response that returns more fields than the client needs — exposing internal IDs, relationship data, audit fields, or other attributes that were never intended to be public.

Detection signal: API responses that serialize full database model objects. Fields like internal_notes, admin_flag, cost_price, or raw_password_hash in API responses. No explicit response schema or serializer allowlist.

Impact: Data that was never intended to be public is available to anyone who calls the API and inspects the full response.

Interrogation question: "For your API responses — is there an explicit list of which fields are returned, or does the serializer return everything on the model? Have you checked the full response for fields that shouldn't be there?"

---

Infrastructure and Supply Chain Threats

Dependency Confusion

What it looks like: Internal package names that, if published to a public registry, would be installed instead of the internal version — because the package manager checks the public registry first.

Detection signal: Internal packages with short, non-namespaced names. Package managers configured to check both internal and public registries without priority ordering.

Impact: An attacker publishes a malicious package with the same name to the public registry. Developers or CI systems install the malicious version.

Interrogation question: "Do any of your internal packages have names that could be registered on npm, PyPI, or RubyGems? What prevents a public package with the same name from being installed instead?"

---

Secrets in Source Control

What it looks like: API keys, database passwords, private keys, or other secrets committed to a git repository — even if later removed, they remain in the git history.

Detection signal: .env files committed to the repository. Secrets hardcoded in config files or source code. Credentials in test fixtures or seed files.

Impact: Anyone with access to the repository (including forks, CI systems, and historical clones) has access to the secrets.

Interrogation question: "Have you ever committed a secret to this repository, even temporarily? Is the git history clean? What would git log -S 'password' or git log -S 'api_key' find?"

---

Third-Party Script Injection

What it looks like: Third-party JavaScript loaded from external CDNs without Subresource Integrity (SRI) checks — meaning the script can be modified at the CDN and the change will be executed in users' browsers.

Detection signal: <script src="https://cdn.example.com/library.js"> without an integrity attribute. Analytics, chat widgets, or A/B testing scripts loaded from third-party domains.

Impact: If the CDN is compromised, an attacker can inject arbitrary JavaScript that runs in the context of your application — reading cookies, intercepting form submissions, or exfiltrating data.

Interrogation question: "For every third-party script loaded in your application — do you have an SRI hash? If that CDN was compromised tonight, what would execute in your users' browsers?"

---

Cloud and Infrastructure Threats

Overpermissioned IAM Roles

What it looks like: Cloud IAM roles, service accounts, or instance profiles with broader permissions than the workload requires — * actions, * resources, or AdministratorAccess attached to application workloads.

Detection signal: IAM policies with "Action": "*" or "Resource": "*". Service accounts with owner or editor roles. Application instances with admin credentials.

Impact: If the workload is compromised, the attacker inherits all of the workload's cloud permissions — potentially including access to all data, the ability to create new resources, or the ability to escalate to full account control.

Interrogation question: "What are the IAM permissions attached to the role this workload runs as? What is the most damaging thing an attacker could do if they compromised this workload and had those permissions?"

---

Public Storage Buckets

What it looks like: Cloud storage buckets (S3, GCS, Azure Blob) configured with public read access, either intentionally for some objects or unintentionally for all.

Detection signal: Bucket ACLs or policies that include AllUsers or * as a principal with read access. Objects uploaded without explicit access control.

Impact: Any data in the bucket is readable by anyone on the internet, including backups, user uploads, logs, and internal reports.

Interrogation question: "For every storage bucket in this system — what is the access policy? Which buckets, if any, are intentionally public? What data could end up in a bucket that is accidentally public?"

---

SSRF (Server-Side Request Forgery)

What it looks like: A feature that fetches a URL supplied by the user — allowing an attacker to make the server send requests to internal services, cloud metadata endpoints, or other targets not accessible from the internet.

Detection signal: URL fetch features (link previews, webhook validation, import from URL). Any server-side HTTP client that accepts a URL from user input.

Impact: An attacker can use the server as a proxy to reach internal services (databases, admin panels), read cloud instance metadata (including IAM credentials), or scan the internal network.

Interrogation question: "Does any part of this system make an HTTP request to a URL provided by a user? What happens if that URL is http://169.254.169.254/latest/meta-data/?"