How it works
Applications can be attacked through weak input handling, broken access control, unsafe configuration, exposed secrets, or missing logs.
Prefer input validation, safe query methods, permission checks, logging, backups, and incident response steps that match the evidence.
Common error
Do not publish logs that contain sensitive data. Logs help defenders, but they must be protected too.
Worked example
A user can request another student record by changing an identifier in the application request. Identify the missing control.
Evidence
Authenticated user: student A
Requested record owner: student B
Server result: record returned
Ownership check: absentThe server must authorize access to each requested record, not merely verify that someone logged in. Restrict the query or record operation to the current permitted scope, log relevant access safely, and verify allowed and denied cases. Hiding an identifier in the interface is not a server-side permission check.
Exercises
5.4.1
Why is client-side input validation insufficient as the only protection for an application endpoint?
Show solution
A client can send requests outside the expected interface. The server must validate input and enforce authorization for every relevant operation.
5.4.2
After correcting the record-ownership check, give one positive and one negative regression test.
Show solution
Positive: student A can read their own permitted record. Negative: the same authenticated student cannot read student B records by changing an identifier. Verify the denial does not expose sensitive details.