APIs have become central entry points into systems, making them prime targets for attackers. Security flaws at the API layer can expose critical data or allow dangerous actions, even when the UI seems harmless. As a QA engineer, understanding API security risks and threat models helps you design tests that catch real vulnerabilities instead of only checking happy paths.
Common API Security Risks and OWASP Guidance
Typical API risks include broken authentication, broken access control, excessive data exposure, lack of rate limiting, injection flaws, and misconfigured security headers. The OWASP API Security Top 10 provides a widely used list of these risks. Threat modelling complements this by asking what an attacker wants, what assets they can reach, and how different components could be abused.
# Example threat modelling questions for an API
- What sensitive data does each endpoint expose?
- Which roles or clients should be allowed to call it?
- What happens if input is malicious, missing, or extreme?
- Can an attacker chain endpoints or parameters to escalate access?Threat models can be lightweight. Even simple diagrams or lists of trust boundaries and data flows help identify where to focus testing. Over time, you can refine these models as you learn more about the system and as new features are added.
Integrating Threat Modelling into Test Design
Use threat models to prioritise tests around authentication, authorization, data flows, and error handling. For each risk, design both positive and negative scenarios: what should be allowed, what should be blocked, and how the API should respond when misuse occurs. This ensures your test suites cover realistic attack paths instead of only functional expectations.
Common Mistakes
Mistake 1 — Treating API security as someone else’s job
This leaves obvious vulnerabilities untested.
❌ Wrong: Assuming security teams or tools will handle all API risks.
✅ Correct: Incorporate basic security checks and threat thinking into regular API testing.
Mistake 2 — Testing only obvious happy paths
Attackers rarely follow intended flows.
❌ Wrong: Never sending malicious, unexpected, or extreme inputs to APIs.
✅ Correct: Design tests that mimic attacker behaviour within safe limits.