Learning outcomes
- Derive testable application security requirements from protection needs and abuse cases.
- Keep untrusted data separate from interpreters, paths, browser code, and executable object graphs.
- Design browser, server-side fetch, object authorization, concurrency, and safe-failure boundaries.
- Verify the deployed application and manage vulnerabilities through remediation and learning.
Scenario
A multi-tenant administration application accepts browser and API requests, generates reports, imports remote data, stores uploaded files, and triggers asynchronous workers. The team must protect each path without assuming route authentication makes the application safe.
Ordered learning units
Secure Software Development Lifecycle
Integrate security requirements, design review, safe implementation, verification, release controls, and vulnerability response.
Build application security requirements
Turn application risks into testable security requirements, assurance levels, negative tests, and evidence with OWASP ASVS.
Vulnerability and Exploit
Distinguish a software weakness, exploitable vulnerability, exploit path, exposure, and resulting security impact.
Input Validation and Output Encoding
Validate syntax and meaning at input boundaries, then encode untrusted data for the exact output interpreter and context.
Canonicalization
Convert equivalent input representations to one defined form before comparison, validation, authorization, and storage.
Injection
Prevent attacker-controlled data from changing the structure or meaning of a command sent to an interpreter.
SQL Injection
Keep untrusted values separate from SQL structure with parameterized queries, allowlisted identifiers, and narrow database authority.
Command Injection
Avoid command interpreters and pass fixed executables and validated arguments through structured process APIs with narrow authority.
Validate and encode untrusted data
Build typed validation, canonicalization, parameterization, sanitization, and output encoding at every application boundary.
Same-Origin Policy
Understand how scheme, host, and port define a browser origin and limit cross-origin reads, script access, and storage.
Cross-Site Scripting (XSS)
Prevent untrusted data from executing as active browser content through context-aware encoding, safe DOM APIs, and constrained markup.
Cross-Site Request Forgery (CSRF)
Stop another origin from causing an authenticated browser to perform an unwanted state-changing request.
Cross-Origin Resource Sharing (CORS)
Grant selected browser origins permission to read cross-origin responses without treating CORS as authentication or request blocking.
Secure browser origin boundaries
Design origins, sessions, cross-origin reads, state changes, frames, messages, and scripts as separate browser security controls.
Server-Side Request Forgery (SSRF)
Prevent untrusted input from making a server reach internal services, cloud metadata, local files, or other unapproved destinations.
Defend outbound requests from SSRF
Design a webhook, import, preview, or fetch service with strict destination, redirect, credential, egress, and resource policy.
Path Traversal
Prevent attacker-controlled file names and paths from escaping an approved storage root after decoding and canonical resolution.
File Upload Security
Validate, transform, store, scan, and serve untrusted files through bounded stages with separate names, origins, and authority.
Unsafe Deserialization
Treat serialized objects as untrusted data and prevent input from selecting executable types, constructors, hooks, or object graphs.
Race Condition and TOCTOU
Prevent security decisions from becoming stale before the protected state change, resource use, or authorization commit completes.
HTTP Request Smuggling
Prevent HTTP intermediaries from disagreeing about message boundaries, request length, transfer coding, and the start of the next request.
Business Logic Abuse
Protect workflow order, object state, quotas, prices, approvals, and other business invariants from valid-looking misuse.
Test application authorization
Verify object, property, action, workflow, tenant, and administrative authorization with a systematic identity and state matrix.
Secure Error Handling
Fail safely without bypassing controls, exposing sensitive internals, duplicating effects, or leaving partial security state.
Security Misconfiguration
Prevent unsafe defaults, unnecessary features, exposed diagnostics, excessive authority, and configuration drift across environments.
Memory Safety
Prevent spatial, temporal, initialization, and type-safety errors that can corrupt memory, disclose data, or redirect control flow.
Manage application vulnerabilities
Receive, reproduce, triage, remediate, verify, disclose, deploy, and learn from application vulnerability reports.
Evaluation questions
- Can you state the security requirement and final protected result for every control in one real feature?
- Can untrusted data become structure in any database, process, path, template, browser, parser, or queue boundary?
- Do route, object, property, action, workflow, transaction, and tenant decisions remain separate and testable?
- Does the system preserve its invariants during concurrency, dependency failure, retry, rollback, and recovery?
Completion conditions
- Build and review a threat and requirement model for one deployed application feature.
- Run negative tests for injection, browser intent, cross-origin reads, server-side fetch, object authorization, file handling, concurrency, and direct-origin bypass.
- Produce evidence for the deployed artifact, configuration, final state, vulnerability response owner, and residual risk.
