Thinking like an attacker
🏠The everyday picture
A shop owner who locks the front door but leaves the back door open, the window latch broken, and the safe code on a sticky note. Security is only as strong as the weakest entrance.
📘What it really is
- Assume every request might come from someone trying to misuse your API, with tools, not a browser. They can:
- send any method, path, header or body;
- change ids in addresses to reach other people's data;
- send huge, malformed or malicious input;
- repeat requests thousands of times;
-
read all your frontend code.
-
The OWASP API Security Top 10 lists the most common API weaknesses. The top ones:
- broken object-level authorisation: changing
/enquiries/E101to/E102shows someone else's data; - broken authentication: weak sign-in, sessions or tokens (Module 44);
- broken property-level authorisation: sending or seeing fields you shouldn't (
isAdmin: true); - unrestricted resource use: no limits on size, rate or cost;
-
broken function-level authorisation: ordinary users calling admin endpoints.
-
Defence in depth: several layers (validation, permissions, limits, logs), so one mistake isn't a disaster.
- Least privilege: every user, service and key gets only the access it needs.
🖱️Try it
Read the OWASP API Security Top 10 summary (owasp.org). For each of the five risks above, write one specific way it could happen in your enquiries API, and whether your API currently prevents it.
✅Quick check
An attacker changes the id in /enquiries/E101 to E102. What weakness is this testing?
Show the answer
Broken object-level authorisation: whether the API checks the person may see that specific item.
What does "least privilege" mean?
Show the answer
Giving each person, service or key only the access it needs, nothing more.