Planning and scoping the test
- ASVS 5.0 verification records: requirement, test and evidence another engineer can repeat
- Review a code change through its trust boundaries
- Combine static and dynamic tests around a verified finding
- Place each security control in the pipeline and decide what it blocks
- Start with a VDP, then add bug bounties and penetration tests
- Choose and evaluate application security testing tools
- Ship without debug modes, verbose errors or exposed files
Practice: Release evidence lab
Authorization and business logic
- Enforce authorization for every object action
- Authorize functions and fields as well as objects
- Preserve business invariants under concurrent requests
- Prevent business-logic flaws with server-side invariants
- Authorization models: RBAC, ABAC, ReBAC and policy as code you can test
- Test smart contracts through state invariants
- DeFi attack patterns: oracles, flash loans, proxies and signatures
Practice: IDOR lab · Race condition lab · Project: Secure a real HTTP API · Project: Make a checkout transaction atomic
Injection and parsers
- Keep untrusted values out of executable syntax
- Prevent XSS at the output boundary
- Fix SQL injection in Python sqlite3
- Fuzz a parser and turn crashes into lasting regressions
- Parse bounded JSON and XML into an explicit application schema
- Keep untrusted object keys out of prototype and authority paths
- Run external programs without command or argument injection
- Keep untrusted input out of eval, expression languages and templates
Practice: Project: Repair a native parser using sanitizer evidence · Project: Parse bounded JSON and XML invoices safely · Project: Stop prototype pollution at merge and authorization boundaries
APIs, protocols and intermediaries
- Apply security limits to GraphQL, WebSocket and gRPC operations
- Bound API work, not just request counts
- Maintain an API inventory and prevent gateway bypass
- Keep HTTP request boundaries consistent across intermediaries
- Prevent shared-cache poisoning and private-response deception
- Secure WebRTC signaling, TURN relays and media servers
Authentication and tokens
- JWT validation: algorithms, keys, claims and key rollover
- Defend JWTs against forgery, confusion and replay
- Defend OAuth and OIDC against redirect and token attacks
- Session management: cookies, timeouts, rotation and revocation
- SAML single sign-on: verify signed assertions without losing the identity boundary
- Account recovery: password resets, help-desk resets and account linking
Practice: JWT validation lab · Password reset token lab
AI features
- Build evaluations around prohibited outcomes
- Contain prompt injection at the application boundary
- Keep generated output out of executable contexts
- Red-team LLM applications and agents by their effects
- Keep secrets and controls out of hidden context (OWASP LLM08:2026)
Practice: XSS lab · Project: Gate model and provider changes on a versioned red-team corpus · Project: Run model-generated Python in a locked-down container
- Build a permission matrix that separates role, tenant and ownership.
- Observe protected effects rather than relying on status codes or hidden controls.
- Combine manual cases with static, dynamic and fuzz testing, and report scope, failures and retests precisely.
A scoped test charter, a permission matrix and a reproducible findings and retest report.
- Read basic HTTP requests and response bodies.
- Use the connected synthetic fixture or explicitly authorized targets and test identities.
Write a test charter naming target version, environment, permitted accounts and actions, synthetic records, limits, evidence handling and, for a penetration test, the rules of engagement. Assign an owner to stop or resolve unexpected effects. Choose the requirement set, such as ASVS 5.0 at a stated level, so results map to versioned IDs. For a desk exercise, use only the supplied dossier and label observations as supplied. Finish when every planned action is within scope and each conclusion’s evidence can be collected without private customer data.
Create rows for list, single-object read, write, export and bulk actions that exist in the selected fixture. Cross them with owner, same-tenant non-owner, other-tenant user and any relevant privileged role. Write expected access before testing, and use the authorization guide to justify each row. Finish when no expected denial depends only on a hidden button and no expected allow depends merely on a valid login.
Run the connected permission exercise or evaluate its complete fixture, keeping a legitimate success beside each forbidden case. Change one boundary value at a time (object ID, actor, tenant or role) and observe returned fields and datastore effects as well as HTTP status; a denied response can still follow a mutation. Alongside the matrix, run static analysis on the code under test, a dynamic scan of the test deployment and a fuzzer on any parser, and confirm each tool finding by hand before reporting it. Finish when results identify the enforcing boundary and distinguish a real repair from blanket failure.
Produce a report with scope, test ID, exact candidate revision, expected and observed result, reproducible evidence and confidence limits. Preserve original failures and their retests. Tie deployed closure to the actual running artifact, and mark missing paths untested instead of not applicable. Finish when another engineer can repeat the finding and the report makes unsupported conclusions, residual risk and the next owner explicit.
The steps use a connected exercise: IDOR lab: Repair an invoice authorization bug. To build the skills behind this job step by step, follow the learning path AppSec in practice.
Use the blank work product for your system. Compare its required evidence with a completed synthetic example.
Download blank work product Download completed example