Secure Application Security Design and Architecture
Domain 3: Secure Application Design and Architecture
This domain tests secure design principles and how architecture choices create or remove risk. Questions often ask you to select a control that enforces a principle across trust boundaries rather than patch a single endpoint.
Core rules and concepts
- Apply least privilege, separation of duties, defense in depth, fail-safe defaults, complete mediation, and economy of mechanism.
- Draw trust boundaries: browser to API, API to database, service to service, and administrator to application. Every boundary needs authentication, authorization, and validation.
- Use secure defaults and deny by default. A feature should require an explicit grant rather than assume safety.
- Reduce attack surface by removing unused endpoints, services, accounts, and libraries; minimize exposed management interfaces.
- Design for secure failure: if a dependency is unavailable, deny access or degrade safely rather than bypass checks.
- Treat secrets, keys, and configuration as architecture concerns, not deployment afterthoughts.
Worked example
A file-upload feature accepts documents from users. A weak design trusts the browser's content-type check and stores files under the web root with the original name. A sound design validates type and size on the server, generates a random stored name, stores files outside the web root, scans them, and serves them through an authorized endpoint or signed URL. The upload service runs with a least-privilege account that can write only to the upload directory. The reasoning is that each control addresses a different failure: spoofed type, path traversal, malware, direct access, and excessive service privilege.
Traps that cost marks
Do not rely on a network perimeter alone. Do not treat security by obscurity as a primary control. Do not place authorization only in the presentation layer. Do not share highly privileged service accounts across components. Do not assume microservices are secure because they are small.
Design review habit
Trace each request from entry point to data store, note where identity is established, where authorization is enforced, and where data is validated or encoded.