Tested fixes for the weaknesses A06:2025 maps, in Express, Flask, Spring Boot, ASP.NET Core, Next.js, FastAPI, Django, net/http, Rails and Laravel: the vulnerable code, the fix, a wrong fix and the regression tests.
A design that lacks the right controls cannot be fixed by perfect implementation: business-logic abuse, missing limits and broken trust assumptions have to be found before the code is written.
- Threat-model critical flows such as authentication, access control and business logic, and write down the abuse cases.
- Turn security requirements into user stories, with tests for misuse as well as use.
- Use a library of secure design patterns and paved-road components.
- Separate tiers and tenants by design, and add plausibility checks at each tier.
Guides on this site
Review tenant boundaries before implementation
Trace tenant identity through requests, data stores, caches, jobs, and administration, then turn plausible isolation failures into tests.
Preserve business invariants under concurrent requests
Make a balance, reservation or approval rule hold when requests overlap, retry and fail halfway through.
Keep HTTP request boundaries consistent across intermediaries
Trace framing disagreements, reject ambiguous requests and verify what reaches the origin with a real loopback proxy project.
Design a safer file-upload pipeline
Treat upload receipt, content processing, storage, and later delivery as separate security decisions.
Prevent business-logic flaws with server-side invariants
Recompute prices on the server, run workflows as state machines, build reset links from configuration, limit valuable flows, and turn each business rule into an invariant that the database and the tests both check.
Choose a threat modeling method and turn its findings into tests
Use the four-question frame to scope a design, pick STRIDE, attack trees, LINDDUN or PASTA by the question you need answered, and leave behind threat records and abuse-case tests the team can run.
Secure design patterns: a catalogue for insecure-design (A06)
A catalogue of reusable secure-design patterns, grouped by concern, each with when to use it, a short example and the failure it prevents: choke-point authorization, capability tokens, parse-don't-validate, safe-by-default APIs, tenant scoping, fail-closed, idempotency, and more.
Worked threat model: a mobile banking app
A complete worked threat model for a mobile banking-style app: the data-flow diagram and its elements, STRIDE threats on the client, the transport and the backend, and the mitigations mapped to OWASP MASVS v2 controls and current Android and iOS platform APIs.
Worked threat model: an LLM agent with tools
A complete worked threat model for an LLM agent with tools: the data-flow diagram, the threats from prompt injection, excessive agency, data exfiltration, confused-deputy and memory poisoning, and the mitigations, mapped to the OWASP Top 10 for LLM Applications 2026 and the OWASP Top 10 for Agentic Applications 2026.
Bound API work, not just request counts
Protect availability and operating cost with limits on input, per-request work, concurrency, queues, and downstream spending.
Practice
- Race condition lab: Repair a balance check that races · Browser lab
- SSRF lab: Guard an outbound fetch against SSRF · Browser lab
- Business logic lab: Price an order without trusting the client · Browser lab
- Path traversal lab: Serve an uploaded file without path traversal · Browser lab
- SSRF validation lab: Validate a fetch URL with ipaddress · Browser lab
- File upload lab: Accept avatars without publishing pages · Browser lab
- Make a checkout transaction atomic · Local project
- Keep extracted files inside their boundary · Local project
- Repair a real proxy and shared cache · Local project
- Convert untrusted documents in a locked-down container · Local project
References
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.