Security behavior includes operations that must be denied. Verify access by role, ownership and input boundary rather than only successful requests.
Before you start
You should understand inputs, expected outputs and the boundaries of the component under test. State the risk a test should detect before choosing a tool or mock. Distinguish controlled dependencies from real integrations so the result does not imply more coverage than the test actually provides.
The practical goal is to reason through this situation: A user cannot read another user’s record by changing its ID. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Identify forbidden operations
Role and resource ownership create distinct denial cases.
Step 2: Call the server directly
Hidden UI controls do not establish enforcement.
Step 3: Check absence of leakage
Denied actions must not expose data or mutate state.
Worked scenario
A user cannot read another user’s record by changing its ID.
User A changes an account ID in an API request to user B’s ID. The endpoint must reject access even though the request format and authentication are valid. Test a permitted own-account operation as well, so a blanket denial cannot masquerade as correct authorization.
Common mistake
A hidden button is not evidence that the server rejects unauthorized actions.
Verify the behavior
Assert allowed and forbidden results plus unchanged protected state.
Interview exercise
Test object-level authorization.
Answer and reasoning
Call the protected endpoint directly with permitted and forbidden identities and verify no sensitive data or side effect escapes.
Continue learning
Compare the scenario with the Software Testing interview questions and test your understanding with the Software Testing MCQs. For terminology and implementation details, consult the reference material.