A secure workflow needs more than a hidden button or a valid-looking form. Distinguish authentication, authorisation and validation, then apply those checks where an attacker cannot bypass them: on the server.
Separate identity from permission
Authentication establishes who the caller is. Authorisation decides what that caller may do with a particular resource. A signed-in user should not gain access to another account merely by changing a record ID in a URL. Check ownership or a suitable permission for every protected read and write.
Treat browser input as untrusted
A visitor can bypass JavaScript validation or send a request directly. Validate the expected shape, type and limits on the server. Use parameterised database queries and escape output for the context where it is rendered. These controls solve different problems; using one does not make the others unnecessary.
Protect sessions and handle failure safely
Use HTTPS, suitable session-cookie settings and the framework protections appropriate to the request, including CSRF defences for cookie-authenticated writes. Keep secrets out of public assets and logs. Show a useful recovery message without exposing stack traces or credentials, and verify that rejected operations leave stored data unchanged.
Worked example
Imagine two users who each own a private preparation note. A security test should request user B’s note while signed in as user A and confirm that access is denied. Hiding the note in the interface is not enough if the endpoint still returns its body.
Check your understanding
Try each question before opening its explanation. These are free practice prompts; they do not use game chances.
Is input validation an ownership check?
No. A record ID can be a valid integer and still refer to someone else’s record. Validate the input and separately check the caller’s permission for the resource.
Does escaping HTML prevent SQL injection?
No. HTML escaping protects a rendering context. Parameterised database operations keep query structure separate from input values; the controls are not interchangeable.
What should a denied edit change in the database?
It should change none of the protected record’s fields. A meaningful test compares the stored record before and after the rejected request, rather than checking only the status code.
Sources and further reading
These original examples explain foundational concepts. Use the official references for complete, current details and version-specific behaviour.
About this guide: AI-assisted educational content with original examples and linked primary references. Found an issue? Tell us what to improve.