Secure Application Design
- Explain input handling, authorization, and safe failure
- Apply the idea to evidence from a realistic technology scenario
- Justify a decision using security, reliability, cost, and user impact
Secure Application Design
Secure applications validate untrusted input, keep data separate from commands, verify authorization on every protected action, manage sessions safely, and fail without exposing secrets. Security must be designed into data flow rather than added only at the login screen.
Decision lens
Strong technical decisions connect evidence → mechanism → impact → response. Identify what the evidence shows, explain the system behavior that produced it, state the likely effect on people or data, and choose a response that addresses the cause without creating unnecessary disruption.
Changing /account/1042 to /account/1043 in a browser reveals another customer’s statement.
- 1.The server accepts an object identifier supplied by the user.
- 2.Authentication succeeded, but object-level authorization failed.
- 3.The server must verify that the signed-in user may access the requested record.
- 4.Log and review attempts to enumerate identifiers.
Which control best prevents SQL injection?
Which response best demonstrates complete reasoning about input handling, authorization, and safe failure?
For a scenario about input handling, authorization, and safe failure, identify the decisive evidence before naming a response. A defensible conclusion here is: This is an authorization flaw; hiding or randomizing the URL is not a substitute for server-side access checks.
Answer the 2 checkpoints as you read.
Sign in to save your progress