0x1337c0d3/stride

STRIDE Threat Model

Analyze the codebase across all 6 STRIDE threat categories. Each category maps to a violated security property and a set of concrete code patterns to detect.

Framework Reference

Load ../../references/stride.md for the full STRIDE category definitions, applicable controls, CWE mappings, and OWASP cross-references.

Usage

/sentinel:stride                          # Full STRIDE analysis (all 6 categories)
/sentinel:stride --only S,E               # Only Spoofing and Elevation of Privilege
/sentinel:stride --depth deep             # Trace data flows across trust boundaries
/sentinel:stride --fix                    # Include fix suggestions inline

Category Overview

| Letter | Category | Security Property | Finding Prefix | Focus | |--------|----------|-------------------|----------------|-------| | S | Spoofing | Authentication | SPOOF | Token forgery, session fixation, credential theft, identity impersonation | | T | Tampering | Integrity | TAMP | SQL injection, parameter tampering, MITM, file modification, XSS | | R | Repudiation | Non-repudiation | REPUD | Missing audit logs, log tampering, insufficient forensic evidence | | I | Information Disclosure | Confidentiality | DISC | Error message leaks, sensitive data in logs, cleartext transmission | | D | Denial of Service | Availability | DOS | Resource exhaustion, ReDoS, no rate limiting, decompression bombs | | E | Elevation of Privilege | Authorization | PRIV | Broken access control, IDOR, JWT manipulation, role confusion |

Workflow

Step 1 — Scope

Default scope: full codebase. Build a focused file list for each category:

| Category | File Patterns to Prioritize | |----------|---------------------------| | S - Spoofing | Auth controllers, session middleware, token validation, login/register routes | | T - Tampering | Input handlers, database queries, API endpoints, file operations | | R - Repudiation | Logging config, audit trail, transaction records, security event handlers | | I - Info Disclosure | Error handlers, API responses, log statements, config files, env vars | | D - DoS | Input parsers, regex patterns, resource allocation, file uploads, rate limiting | | E - Privilege Escalation | Authorization middleware, role checks, admin routes, RBAC config |

Step 2 — Analyze Each Category

Work through each relevant category (all 6 by default, or --only selection).

For each category, look for the patterns below and produce findings.

---

S — Spoofing Patterns

• JWT with alg: none accepted or algorithm not validated
• Session tokens generated with Math.random() or non-cryptographic RNG
• Session fixation: session ID not rotated after login
• Password comparison with == instead of constant-time comparison
• OAuth state parameter missing or not validated
• Token expiry not enforced (no exp claim check)
• Cookie missing HttpOnly, Secure, or SameSite flags
• Auth bypass via HTTP method override or X-HTTP-Method-Override

---

T — Tampering Patterns

• User input directly concatenated into SQL queries (SQLi)
• User input reflected in HTML without encoding (XSS)
• Server-side template injection (user input in template strings)
• Command injection (user input in shell commands, exec, system)
• File path traversal (../ in file operations)
• Mass assignment: request body bound to model without allowlist
• Prototype pollution in JavaScript
• Deserialization of untrusted data without type/integrity checks

---

R — Repudiation Patterns

• Security-sensitive actions (login, password change, payment) not logged
• Logs do not include: user identity, timestamp, IP, action, outcome
• Application-level log deletion or modification is possible
• No tamper-evident logging (logs writable by application process)
• Admin actions not recorded in audit log
• Log aggregation to remote store not configured

---

I — Information Disclosure Patterns

• Stack traces or exception details returned in production responses
• Internal hostnames, IPs, or paths in error messages
• Sensitive fields (passwords, tokens, SSNs) included in API responses
• Secrets or credentials logged
• Debug endpoints active in production (/debug, /metrics with internals)
• Directory listing enabled on static file server
• Source maps exposed in production build

---

D — Denial of Service Patterns

• Regular expressions vulnerable to catastrophic backtracking (ReDoS)
• No rate limiting on authentication endpoints
• No maximum payload size enforced on file upload or JSON body
• Recursive or deeply nested input parsing without depth limit
• Unbounded database queries (no LIMIT, no pagination)
• XML/YAML parsing without entity expansion protection (XXE, Billion Laughs)
• No timeout on external HTTP calls
• Resource-intensive operations callable without authentication

---

E — Elevation of Privilege Patterns

• Authorization check missing on sensitive endpoints (only authentication checked)
• IDOR: resource accessed by ID without ownership validation
• Role check performed on client side only
• Horizontal privilege escalation: user can access other users' data by changing ID
• Admin routes accessible to non-admin roles
• JWT role or isAdmin claim modifiable without signature verification
• RBAC misconfiguration: overly permissive wildcard permissions
• Privileged operation available via indirect reference (e.g., batch API)

---

Step 3 — Findings Format

For each finding:

[STRIDE-XXX] Title
Category: [S/T/R/I/D/E] | Severity: CRITICAL/HIGH/MEDIUM/LOW | CWE: CWE-XXX
Location: file:line | Confidence: HIGH/MEDIUM/LOW

STRIDE category: [Category name] — [Security property violated]

Attack scenario:
1. [Attacker action]
2. [What the code fails to do]
3. [Impact]

Evidence:
  [vulnerable code snippet]

Fix:
  [corrected code + one-line explanation]

OWASP: [OWASP 2021 category] | Compliance: [relevant frameworks]

Step 4 — Per-Element Threat Matrix

Build a matrix showing which STRIDE categories produced findings per component:

| Component | S | T | R | I | D | E | Findings |
|-----------|---|---|---|---|---|---|----------|
| Auth controller | X | | | | | X | SPOOF-001, PRIV-002 |
| API gateway | | X | | X | X | | TAMP-001, DISC-003 |

Step 5 — Report

Produce findings ranked by severity. Then the threat matrix. Then write report:

OUTPUT_DIR=$(git rev-parse --show-toplevel 2>/dev/null || echo "$PWD")
REPORT_FILE="${OUTPUT_DIR}/stride-$(date +%Y%m%d).md"

Save the full report to ${REPORT_FILE}.

Step 6 — Sentinel Integration

If Sentinel has run recently (check for reports/security-*.md):

• Cross-reference STRIDE findings with Sentinel SENTINEL-XXX findings
• Map each Sentinel finding to its STRIDE category
• Note findings Sentinel found but STRIDE did not (tool-detected vs architecture)
• Note findings STRIDE found but Sentinel did not (logic/architecture vs code patterns)
• Produce combined summary: "Sentinel detected N tool-level findings. STRIDE identified M architectural threats. X overlap."

Severity Guidance

| Severity | Criteria | |----------|----------| | CRITICAL | Auth bypass (S/E), RCE via injection (T), mass data disclosure (I) | | HIGH | SQLi, stored XSS, IDOR on sensitive data, no rate limit on auth | | MEDIUM | Reflected XSS, log gaps, excessive data exposure, ReDoS on public input | | LOW | Missing security headers, verbose errors, minor info disclosure |

---

Report Format

Format your final output following the standard Sentinel report structure defined in ${CLAUDE_SKILL_DIR}/../../templates/report.md. Use your skill's domain-specific finding IDs (e.g. STRIDE-SPOOF-001, RT-SK-001, API-001) in the Finding ID column. Include the Security Scorecard and Findings sections as a minimum. Omit the Cross-Validation Summary section if you ran only AI analysis (no tool comparison).