STRIDE · Security analysis · Architecture-aware
AI Threat Model Generator
for Modern Web Apps
STRIDE-based threat analysis generated from your architecture description — not generic security checklists. Injection vectors, auth weaknesses, data exposure risks, and mitigations in your threat model.
The problem with security checklists
A threat model that doesn't know your stack is decoration.
Most teams either skip threat modeling entirely or reach for the OWASP Top 10 as a substitute. The OWASP Top 10 is useful — it's a good reminder that SQL injection still exists and that access control failures are perennially underestimated. But it applies to every web application equally, which means it applies to yours with the precision of a horoscope.
The threat surface of a Cloudflare Workers app using Durable Objects for session state is not the same as a Node.js app using Redis. JWT algorithm confusion attacks are irrelevant if you're using session cookies with D1-backed storage. Slow HTTP DoS via large POST bodies matters differently at the edge where the worker terminates before reaching your handler. KV cache poisoning is a real attack vector if you're using user-supplied input as cache keys — and it won't appear in any generic checklist.
An architecture-aware threat model knows your actual stack. It knows you're running at the edge, that your session store is D1, that your auth is cookie-based, that your files live in R2. The threats it surfaces map to the actual components in your system. The mitigations are actionable. The severity ratings reflect your actual exposure, not a worst-case generic web-app scenario.
Threat models also have a second purpose that checklists can't serve: they link to your architectural decisions. When ADR-003 documents "don't expose raw database errors to clients," it's because T-004 (information disclosure via verbose SQLite error messages) is in your threat model. When you change your error handling strategy, the reason is traceable. That traceability is what makes a threat model useful for more than a single sprint.
Stackbilder generates threat models that know your stack — currently Cloudflare Workers with D1, KV, R2, and Durable Objects.
What Stackbilder generates
Six STRIDE categories. Stack-specific threats. Actionable mitigations.
Spoofing
JWT algorithm confusion (alg:none bypass). Attacker crafts a token the server accepts without a valid signature. Mitigation: strict algorithm allowlist, reject tokens without a signature.
Tampering
D1 row modification via IDOR. Attacker updates a record by supplying another user's ID. Mitigation: always filter queries by session-derived tenant_id, never by user-supplied ID alone.
Repudiation
No audit trail for privileged operations. Admin deletes a record with no immutable log entry. Mitigation: append-only audit table with admin action logging before any destructive write.
Information Disclosure
D1 verbose error messages expose schema. SQLite errors return table/column names to the client. Mitigation: sanitize all database errors before client response — log full error server-side only.
Denial of Service
Durable Object hotspot under burst load. Single DO instance serializes all requests — burst traffic queues and times out. Mitigation: per-session DO naming, queue depth cap with 429 response.
Elevation of Privilege
Missing role check on admin-only route. Middleware validates auth but not role. Mitigation: explicit role assertion in middleware before handler runs; role sourced from session, not request body.
Stack shapes the threats
The same threat class looks entirely different depending on your architecture. Elevation of Privilege in a JWT-based system involves token forgery. In a cookie-session system backed by D1, it involves session table manipulation or brute-forcing session tokens. In a Cloudflare Workers service binding scenario, it involves a downstream worker accepting requests from any caller without verifying origin. The threat model adapts to your actual stack — it doesn't report generic threats and let you figure out the mapping.
Downstream worker accepts requests from any
caller without verifying X-Internal-Token.
Vector: internal network, no auth required
Mitigation: validate shared secret in downstream
worker before processing any request.
Threats link to ADRs
Every threat that drove an architectural decision is cross-referenced to the ADR that addresses it. T-004 (information disclosure via verbose error messages) links to ADR-003 (error sanitization policy). This means when someone asks "why do we sanitize database errors?" there's a traceable answer in the governance artifacts — not tribal knowledge. It also means threat items are clearly resolved (there's an ADR for it) versus open (no mitigation ADR exists yet).
D1 error messages expose schema via verbose
SQLite error strings.
Status: Mitigated → ADR-003
ADR-003: Error sanitization — all D1 errors
mapped to generic 500 before client response.
Example output
A real threat model excerpt — not a template.
This is the format of threat items generated for a Cloudflare Workers SaaS with multi-tenant D1, cookie auth, and Stripe webhooks. Eight items shown from a twelve-item model.
# Threat Register — Multi-tenant SaaS on Cloudflare Workers
Generated by Stackbilder · Architecture: Workers + D1 + Cookie Auth + Stripe
Session token brute-force
Spoofing · Cookie token entropy below 128 bits
↳ Generate session tokens with crypto.getRandomValues(), 256-bit minimum
IDOR on D1 row updates
Tampering · User-supplied record ID in PUT body
↳ Always JOIN with session tenant_id; reject mismatches at query layer
No audit log for billing actions
Repudiation · Stripe webhook handler has no immutable log
↳ Append-only billing_events table; log before DB write
D1 error schema leakage
Info Disclosure · SQLite errors returned verbatim to client
↳ Map all D1 exceptions to 500 before response → ADR-003
Webhook replay flooding
DoS · Stripe webhook endpoint accepts replays
↳ Validate Stripe-Signature; reject events > 5 min old
KV key-space exhaustion
DoS · Unauthenticated endpoint writes to KV
↳ Rate-limit writes; require auth on all KV-write paths
Stripe webhook tier skip
EoP · Forged webhook upgrades arbitrary user tier
↳ Verify signature before any tier mutation; idempotency key check
WAF bypass via .dev origin
Info Disclosure · Direct access to worker.dev bypasses zone WAF
↳ Validate X-Custom-Secret header; return 403 without it
How it works
Your architecture in. A STRIDE threat model out.
Describe your architecture
Tell Stackbilder what you're building: auth method, data store, external integrations, user trust levels. "Multi-tenant SaaS with cookie sessions, D1, Stripe webhooks, and an admin role" gives the engine what it needs.
Threat analysis in 20ms
The TarotScript engine maps your architecture to its threat surface — the STRIDE categories that apply to your specific binding patterns, auth strategy, and integration points. Threat items are generated with severity, attack vector, and concrete mitigation. Deterministic: same input, same output.
Threats that link to decisions
Threat items that drove architectural decisions cross-reference the ADRs that address them. Your threat model and your decision records are a coherent document set — not two disconnected outputs.
Common questions
What is a STRIDE threat model?
STRIDE is a structured way to analyze threats across six categories: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. It gives you a systematic lens instead of an ad-hoc list of scary scenarios. Each threat category has a different mitigation pattern, so the framework directly guides your response.
How is this different from an OWASP checklist?
OWASP checklists are stack-agnostic — they apply to all web apps equally. Stackbilder's threat model is architecture-aware: it knows your actual data stores, auth method, and integration points. A Cloudflare Workers app using Durable Objects gets different threats than a Node/Postgres app. Generic checklists can't make that distinction.
Does the threat model update when my architecture changes?
You regenerate when your architecture changes. Because the engine is deterministic, re-running with an updated description produces a new threat model that reflects the new surface. ADRs document what changed and why, so the threat model evolution stays traceable.
Is the threat model output suitable for SOC 2 or audit purposes?
It establishes that threat analysis was performed with documented mitigations — a useful artifact for auditors. For SOC 2 Type II, pair it with evidence of the mitigations implemented, which the test plan helps you establish. Whether it satisfies a specific auditor depends on scope and their requirements.
How many threat items does a typical scaffold include?
A Cloudflare Workers SaaS scaffold typically generates 8–14 threat items across the six STRIDE categories. More complex architectures — Durable Objects, worker-to-worker bindings, Stripe webhooks, multi-tenant D1 — produce more items because the attack surface is larger. Every item includes severity, attack vector, and mitigation.
Related pages
Threat models that know your stack.
Free tier includes 3 scaffolds per month — threat model, ADRs, and test plan with every one. No credit card.