Applied · Module 4
API and service security
When you review an API, focus on these ideas.
Previously
Web security in practice
Most breaches start with what is exposed, not with exotic zero days.
This module
API and service security
When you review an API, focus on these ideas.
Next
Verification and release gates
In practice, you verify three things.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
Check identity and permission on every sensitive action server side.
What you will be able to do
- 1 Explain why APIs are a common path for abuse
- 2 Name four checks that protect high impact endpoints
- 3 Explain idempotency for retries and side effects
Before you begin
- Foundations-level vocabulary and concepts
- Confidence with basic diagrams and section terminology
Common ways people get this wrong
- Broken authorisation. Most serious incidents are access control failures, not crypto failures.
- Replay and reuse. If tokens can be replayed, attackers turn one mistake into a habit.
Main idea at a glance
Diagram
API trust decision path
`flowchart LR
Request["API request"] --> AuthN{"Authenticated"}
AuthN -->|"No"| RejectA["Reject and log"]
AuthN -->|"Yes"| AuthZ{"Authorised action"}
AuthZ -->|"No"| RejectZ["Reject and alert on abuse patterns"]
AuthZ -->|"Yes"| Rate{"Rate limit passed"}
Rate -->|"No"| Throttle["Throttle or block"]
Rate -->|"Yes"| Replay{"Replay safe"}
Replay -->|"No"| RejectR["Reject duplicate side effect"]
Replay -->|"Yes"| Execute["Execute action and audit"]
`API trust decision path
When you review an API, focus on these ideas.
API security review priorities
-
Action-level authentication and authorisation
Check identity and permission on every sensitive action server side.
-
Rate limiting and abuse controls
Limit automated misuse and preserve service availability under load.
-
Scoped credentials and key rotation
Reduce blast radius when keys leak and keep trust material fresh.
-
Replay protection and idempotency
Prevent duplicate side effects when requests are retried or replayed.
Mental model
Service chain security
Distributed systems fail when trust is assumed between services.
-
1
Client
-
2
API
-
3
Downstream service
-
4
Authorisation
-
5
Logs
Assumptions to keep in mind
- Service identity exists. Services need identities too. Otherwise internal calls become an unpoliced trust zone.
- Authz is consistent. If the API enforces policy but the service does not, the back door is open.
Failure modes to notice
- Broken authorisation. Most serious incidents are access control failures, not crypto failures.
- Replay and reuse. If tokens can be replayed, attackers turn one mistake into a habit.
Check yourself
Quick check. APIs
0 of 4 opened
Why are APIs high impact
They expose powerful actions between systems, often without a human in the loop.
Scenario. An API key leaks. What should have limited the blast radius
Least privilege scopes, short-lived credentials where possible, rotation, and monitoring for unusual usage.
Why do rate limits matter
They reduce abuse and reduce damage during automated attacks.
Scenario. A payment endpoint is retried because of a timeout. What design property prevents double-charging
Idempotency. The same request should not create multiple side effects when retried.
Artefact and reflection
Artefact
A short API review checklist for one endpoint
Reflection
Where in your work would explain why apis are a common path for abuse change a decision, and what evidence would make you trust that change?
Optional practice
Review one API action and write its auth and rate limit rules