Design
Find the trust boundaries and what can go wrong at each, and choose patterns that hold, before the code is written.
Where are the trust boundaries, and what can go wrong at each?
Start here: Secure a feature · Review a design
Security practices in this phase
Threat modeling
Draw the data flow, mark the trust boundaries and list what can go wrong at each, with a method that fits the team, such as STRIDE or attack trees.
Done when: Each threat has an owner and a decision: mitigate with a named control and test, accept with an expiry date, or change the design.
Secure design patterns
Use proven patterns and components for authentication, authorization, tenancy, secrets and input handling instead of designing them again for each feature.
Done when: The design names the pattern used at each boundary, and any departure is a recorded decision.
Security design review
Have someone who did not design the change check it against the requirements and the threat model, especially authorization, data exposure and failure handling.
Done when: Review findings are tracked like bugs and resolved before the affected part is built.
Guides
69 guides- Review tenant boundaries before implementation
Trace tenant identity through requests, data stores, caches, jobs, and administration, then turn plausible isolation failures into tests.
- WEP: RC4 key reuse and weak IVs
Separate WEP’s repeated-keystream failure, weak-IV key recovery, and unkeyed integrity weakness through a concrete two-packet exercise.
- Flame: MD5 certificate forgery
Follow how a weak digest and an overpowered certificate trust path enabled forged code-signing authority, without equating the event with RSA key theft.
- Lucky Thirteen and POODLE: two different oracles
Compare two CBC oracles by their signal, protocol rules, and attacker prerequisites instead of treating them as interchangeable padding bugs.
- FREAK and Logjam: export-grade key exchange
Trace two export-grade downgrade paths and separate RSA factorization from finite-field Diffie–Hellman discrete logarithms.
- DROWN: one RSA key across incompatible protocols
Map an RSA key across services to see how an SSLv2 oracle could compromise TLS traffic on a different endpoint.
- Sweet32: the cost of a small block size
Read the 2016 Sweet32 demonstrations as evidence about traffic volume, repeated secrets, and session lifetime rather than treating a block-size threshold as an instant exploit.
- ROCA: structured RSA key generation
Understand why mathematically structured RSA primes were factorable despite normal key lengths, then plan replacement around generation provenance.
- Preserve business invariants under concurrent requests
Make a balance, reservation or approval rule hold when requests overlap, retry and fail halfway through.
- 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.
- Threat pattern library for threat modeling
Thirty-two recurring threat patterns grouped by identity, authorization, parsers, concurrency, integrations, data exposure, supply chain, availability and AI agents, each with where it shows up on a data-flow diagram, mitigations, a verification step and STRIDE, CWE and CAPEC links, plus a YAML catalog and a script that lists patterns per diagram element.
- 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.
Also part of this phase
- Design a safer file-upload pipeline
Treat upload receipt, content processing, storage, and later delivery as separate security decisions.
- Verify webhook deliveries before acting
Verify the provider’s signature over the correct bytes, then apply replay, authorization, and idempotency controls before a business action.
- Contain prompt injection at the application boundary
Assume retrieved content can influence model output; enforce data access and consequential actions in components the model cannot authorize for itself.
- Review trust boundaries in mobile and native clients
Protect local data and platform interactions while keeping server-side authorization independent of the client’s behavior.
- ECB mode: why it leaks patterns and what to use instead
Derive exactly what ECB reveals and why a longer key cannot fix it, find where ECB enters real code, and replace it with an authenticated mode.
- Padding oracle attacks
Use a byte-level CBC example to see how a tiny validity signal becomes plaintext information, then design verification that checks more than the error message.
- RC4 keystream bias
Understand why fresh RC4 keys do not remove keystream bias and how repeated secret positions turn a small statistical effect into evidence.
- 64-bit block ciphers and the Sweet32 mechanism
Calculate the birthday effect for 64-bit blocks and derive the CBC relation that can turn a collision into a plaintext disclosure.
- Constrain server-side fetches to their intended destinations
Prevent untrusted URLs from turning a preview, import, or webhook feature into access to internal services.
- Extract archives without escaping the destination
Prevent traversal, link tricks, overwrites and decompression exhaustion while preserving legitimate file extraction.
- Convert untrusted office documents and PDFs in an isolated parser
DOCX, XLSX and ODF files are ZIP archives of XML, and PDFs can carry scripts; the converters that read them are large C and C++ programs with a long CVE history. Check the package before any parser reads it, convert each document in a container with no network, no writable root and hard limits, kill it at a deadline, and re-render to pixels when people will open the result.
- Secure WebRTC signaling, TURN relays and media servers
WebRTC encrypts media, but signaling decides whose keys you trust and TURN relays wherever it is allowed. Authorize every signaling message, mint short-lived TURN credentials, deny internal addresses and harden media servers.
- Review mobile storage, links and platform permissions
Keep local artifacts and platform entry points from exposing authority that belongs on the server.
- Bound background jobs and make retries safe
Keep queues, workers and paid dependencies within a defined budget when clients retry, cancel or disappear.
- GDPR, CCPA, HIPAA or the FTC rule: scope privacy and health-data obligations before choosing controls
Map data, actors and processing purposes to the relevant GDPR, California or HIPAA requirements and preserve uncertainty about applicability.
- AEAD records: AES-GCM nonces, associated data and key limits
Build an encrypted record whose tag binds ciphertext to the intended tenant, record, purpose and format, keep nonces unique within each key’s usage limit, and verify the design with actual AES-GCM.
- Envelope encryption and key rotation: data keys, KMS keys and backups
Encrypt each record with its own data key, wrap that key in a KMS or HSM key, and keep wrapping-key rotation, data re-encryption, key deletion and restored backups as separate, tested operations.
- Operate TLS and certificates: configuration, renewal and verification
Configure a modern TLS profile with hybrid post-quantum key exchange, automate renewal for certificate lifetimes that fall to 47 days, and verify every termination point with a fresh handshake.
- Workload identity federation: short-lived, scoped identities for services and CI
Trace how a running workload obtains a short-lived identity, write cloud trust policies that match immutable claims instead of names or wildcards, and keep the resulting credential limited by audience and authorization.
- Authorization models: RBAC, ABAC, ReBAC and policy as code you can test
Translate roles, attributes and relationships into explicit subject-action-resource decisions, prevent broken object level authorization (BOLA), and verify ownership and tenant boundaries with tests.
- Data minimization and retention: collect less and prove that deletion works
Design collection and deletion around a data-flow graph that includes logs, derived tables, exports and restored backups, and use per-person keys so deletion can reach copies you cannot edit.
- Tokenization, pseudonymization and privacy transformations: choose deliberately
Choose between vault tokens, keyed pseudonyms, format-preserving encryption, aggregation and differential privacy by the joins, reversibility and leakage each allows, and test re-identification on the data you release.
- Post-quantum migration: cryptographic inventory, hybrid TLS and deadlines
Inventory public-key cryptography by operation, owner and lifetime, turn on hybrid ML-KEM key exchange where it is already available, and plan signature and archive migration against the NIST, NSA, NCSC and EU dates.
- Keep retrieval inside the user’s data boundary
Carry document permissions through ingestion, retrieval, caching and citations so a model never receives another tenant’s records.
- Authorize agent tools outside the model
Bind each proposed action to the user, resource and approved arguments before allowing a tool to cause a side effect.
- Keep generated output out of executable contexts
Choose safe rendering and narrow operations so model text cannot become browser code, database syntax or an unrestricted command.
- Build evaluations around prohibited outcomes
Test the application’s actual security boundaries, preserve legitimate tasks and distinguish deterministic enforcement from variable model behavior.
- Red-team LLM applications and agents by their effects
A red-teaming method for LLM features and agents: scope the whole system, map attacks to OWASP and MITRE ATLAS identifiers, score trials from observed effects, report rates with confidence intervals and retest on every model or provider change.
- Bound agent spending, memory and recovery
Enforce budgets and stop conditions outside the model, and make retained context and side effects recoverable.
- Assess extraction, membership and inference risks
Define what an adversary can observe and measure privacy leakage without confusing a model’s output with proof about its training data.
- Constrain MCP and multi-agent trust boundaries
Validate each connection and delegated action without treating a token for another service, a tool description, another agent or a state handle as authority.
- Contain cascading failures and rogue agents
Stop a looping, compromised or drifting agent from spreading harm: kill switches, budget and rate limits, circuit breakers, behavior monitoring, blast-radius limits, quarantine, rollback and incident response, all enforced outside the agent.
- Test smart contracts through state invariants
Define the properties funds and privileges must preserve, then exercise callbacks, transaction sequences and exceptional conditions locally.
- Prevent shared-cache poisoning and private-response deception
Define lookup and storage policy, trace cache/origin interpretation differences and verify both public reuse and private isolation.
- 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.
- Redirect users only to destinations you control
Check every redirect target taken from a request, so attackers cannot borrow your domain for phishing, carry OAuth tokens off-site or steer a server-side fetcher through your redirects.
- Secure the developer workstation: extensions, package managers, secrets and AI agents
Attackers reach the software supply chain through developers' editors, package installs and AI agents. Allow-list extensions, stop install scripts and brand-new versions, keep long-lived secrets off laptops, and lock down repository files that run code when a project opens.
- Choose cryptographic algorithms and parameters by job
A sourced quick reference for October 2026: which algorithm and parameters to use for encryption, hashing, passwords, MACs, signatures, key agreement, key derivation, randomness and TLS, the matching APIs in Node.js, Python, Java, Go and .NET, and where post-quantum migration stands.
- Secure AI-assisted development with coding assistants and agents
Treat generated code, suggested packages, repository text and MCP servers as untrusted inputs, and confine coding agents with OS-level isolation and short-lived, narrowly scoped credentials.
- Write testable security requirements and a security Definition of Done
Derive security requirements from OWASP ASVS 5.0, abuse cases and the threat model, write them as acceptance criteria a test can fail, trace each one to a test or evidence, and close stories against a short security Definition of Done.
- Abuse case library: tests and controls by feature
Recurring abuse cases for sign-up and login, password reset, MFA enrolment, invites, file upload, payments and coupons, webhooks, search, export, admin and AI chat or agents: the attacker goal, preconditions, a concrete test and the control, each linked to CWE and CAPEC.
- GDPR privacy by design for engineers: Articles 25, 32 and 35 in code
Turn GDPR data protection by design and by default, security of processing and DPIA triggers into engineering work: a personal-data inventory checked in CI, defaults that collect and share less, a DPIA screen at design time, and access and erasure requests that reach every store.
- Secrets at runtime: Vault, Kubernetes Secrets, CSI driver, External Secrets and SOPS
How a running workload should get its credentials: encrypt Kubernetes Secrets with a KMS v2 provider and lock down RBAC, mount from an external store with the Secrets Store CSI Driver, sync with External Secrets Operator, issue dynamic credentials with Vault and its Agent Injector, keep Git copies encrypted with SOPS, and make rotation reach the process.
- Case study: the LastPass breach (2022)
How an attacker went from a compromised developer laptop to a DevOps engineer's home computer, the keys to LastPass's cloud backups and a copy of customer vaults; why each vault's safety then rested on its master password and PBKDF2 iteration count; and what it teaches about backup keys, privileged endpoints, KDF upgrades and unencrypted metadata.
- Create temporary files safely: mkstemp, O_EXCL and private directories
Stop symlink, hardlink and pre-created-file attacks on the temporary files your code writes in shared directories such as /tmp: create each file atomically with O_EXCL and owner-only permissions through mkstemp or its equivalent in shell, Python, Java, Node.js, Go, .NET and Rust, keep related files in a private directory, and treat the Linux protected_* sysctls and systemd PrivateTmp as a backstop.
- Consume third-party APIs safely (OWASP API10:2023)
Treat every upstream and third-party API response as untrusted input: validate it against a schema, set connect and read timeouts, cap the response size, refuse to follow redirects blindly, keep TLS verification on, and scope the credentials you hold for each provider.
- Contain LLM misinformation (OWASP LLM07:2026)
Stop plausible but wrong model output from driving decisions and actions: ground answers in sources, verify every citation, separate generation from execution with a claim-check-act pattern, gate consequential actions on a human, and evaluate factuality on your own domain.
- Call a hosted LLM API safely
A code-first checklist for wiring up an OpenAI or Anthropic API call from a backend: keep keys server-side, redact PII before prompts and logs, choose provider retention settings deliberately, validate structured output and still treat it as untrusted, and set timeouts, retries and per-user cost caps.
- DeFi attack patterns: oracles, flash loans, proxies and signatures
The four smart-contract attack classes beyond reentrancy: price-oracle manipulation, flash-loan amplification, upgradeable-proxy storage collisions and uninitialized implementations, and signature replay, each with vulnerable and fixed Solidity, Foundry tests and verified incidents.
- Sandbox model-generated code and computer-use agents
Run the code an agent writes, and agents that drive a browser or desktop, inside a boundary built for hostile code: a disposable runtime with no secrets and no default network, hard resource limits, and a person in front of every side effect.
- Keep secrets and controls out of hidden context (OWASP LLM08:2026)
OWASP LLM08:2026 Hidden Context Exposure, which replaced System Prompt Leakage: why system prompts, tool schemas and retrieved policy text get extracted, what must never be in them, and how to enforce rules where a leak changes nothing.
- Defend agent memory and context against poisoning (OWASP ASI06)
OWASP ASI06 Memory & Context Poisoning: how an instruction or false fact saved once in agent memory, conversation summaries or a retrieval store steers later sessions, users and agents, and the write, scope, provenance, expiry and recovery controls that contain it.
- Case study: Moffatt v. Air Canada, a chatbot that misstated the refund policy (2022-2024)
How an airline's website chatbot told a grieving customer they could claim a bereavement fare after travel, what the British Columbia Civil Resolution Tribunal decided in February 2024, and the grounding, testing and correction practices that keep an automated answer consistent with the policy it describes.
- Case study: the Nx s1ngularity compromise and its AI-assisted payload (2025)
How a pull-request-title injection in a GitHub Actions workflow on an outdated branch gave an attacker the Nx npm token in August 2025, how the malicious versions tried to turn developers' own AI command-line tools into file-search agents, and the workflow, publishing and agent controls that stop the same chain.
- Case study: the Amazon Q Developer extension compromise (2025)
How an over-scoped GitHub token, extracted from an AWS CodeBuild pull request build, let a threat actor commit code to the Amazon Q Developer extension for VS Code that shipped in version 1.84.0 in July 2025, why the injected code aimed at the Q Developer CLI failed, and the CI and AI-agent controls the incident argues for.