Application, API, and Cloud Attacks with Mitigation Mapping
Key Takeaways
- Application attacks often exploit input handling, authorization, session management, insecure design, or exposed components.
- Injection sends untrusted input to an interpreter; XSS runs attacker-controlled script in a user browser.
- Broken access control includes IDOR, privilege escalation, and missing object-level authorization.
- API attacks commonly target weak authentication, excessive data exposure, mass assignment, and missing rate limits.
- Cloud attacks often abuse misconfiguration, exposed storage, overly permissive IAM, metadata services, and leaked keys.
Last updated: April 2026
Application, API, and Cloud Attacks with Mitigation Mapping
For application and cloud questions, identify the failed control: input validation, output encoding, authorization, authentication, session protection, secret handling, or configuration management.
Application Attack Map
| Attack | What the attacker does | Example clue | Primary mitigations |
|---|---|---|---|
| SQL injection | Sends input that changes database query logic | ' OR '1'='1 in login field | Parameterized queries, input validation, least-privilege DB account |
| Command injection | Runs OS commands through app input | ; cat /etc/passwd | Avoid shell calls, allow lists, sandboxing |
| XSS | Runs script in another user's browser | Stored comment executes JavaScript | Output encoding, sanitization, CSP, HttpOnly cookies |
| CSRF | Tricks authenticated browser into unwanted action | Hidden form submits transfer | Anti-CSRF tokens, SameSite cookies, reauthentication |
| Directory traversal | Accesses files outside intended path | ../../etc/passwd | Canonicalize paths, allow lists, least privilege |
| SSRF | Server is tricked into making internal request | App fetches metadata URL | Egress filtering, metadata protections, URL allow lists |
| Race condition | Timing issue changes expected result | Double-spend or duplicate redemption | Locking, atomic operations, idempotency |
| Insecure deserialization | Malicious object triggers code or logic abuse | Tampered serialized token | Safe formats, signing, validation |
| Buffer overflow | Input exceeds memory boundary | Crash or code execution in native app | Memory-safe languages, bounds checks, DEP/ASLR |
API Attack Map
| API weakness | Scenario clue | Mitigation |
|---|---|---|
| Broken object-level authorization | /api/users/1001 changed to /api/users/1002 works | Check authorization for each object |
| Excessive data exposure | API returns SSN though UI hides it | Return only required fields |
| Mass assignment | User sets "isAdmin": true in JSON | Bind allowed fields only |
| Missing rate limits | Token endpoint hammered by bots | Per-user and per-IP throttling |
| Weak token handling | Long-lived bearer token in local storage | Short-lived scoped tokens, secure storage, rotation |
| Poor versioning | Old vulnerable API remains exposed | Inventory, deprecate, gateway controls |
Cloud Attack Map
| Cloud issue | Attack path | Mitigation |
|---|---|---|
| Public object storage | Anonymous users read sensitive files | Block public access, bucket policy review |
| Overly permissive IAM | Compromised user can administer account | Least privilege, permission boundaries, access reviews |
| Leaked access key | Key in repo or image is used externally | Secret scanning, rotation, workload identity |
| Metadata service abuse | SSRF retrieves temporary credentials | IMDS protections, egress allow lists, SSRF fixes |
| Open security group | Management port exposed to internet | Restrict source, VPN or bastion, just-in-time access |
| Insecure container image | Known vulnerable package deployed | Image scanning, patching, signed images |
| Misconfigured logging | Attack leaves little trace | Enable audit logs, centralize, protect retention |
Mitigation Selection Worked Example
An API endpoint lets an authenticated user request /api/invoices/8571. Changing the ID to 8572 returns another customer's invoice. This is not SQL injection unless database syntax is involved. It is broken object-level authorization, often called IDOR. The fix is to check that the authenticated principal is authorized for the requested invoice object every time.
| Wrong fix | Why it is incomplete |
|---|---|
| Hide invoice IDs in the UI | Attackers can still modify requests |
| Encrypt transport with TLS | TLS protects the request in transit but does not enforce authorization |
| Add a WAF only | WAF may reduce obvious attacks but cannot know business ownership reliably |
| Rename the endpoint | Security through obscurity does not fix missing authorization |
Common Traps
| Trap | Better exam reasoning |
|---|---|
| XSS versus CSRF | XSS executes script in the browser; CSRF abuses an authenticated browser to submit an action |
| Injection versus IDOR | Injection changes interpreter commands; IDOR bypasses object authorization |
| WAF as the only answer | WAF is compensating; fix code or configuration when possible |
| Cloud provider blamed for customer IAM mistakes | In cloud, customer configuration and identity choices are often customer responsibility |
Quick Drill
- User input becomes part of a SQL WHERE clause: use parameterized queries.
- API returns another user's record after changing only an ID: enforce object-level authorization.
- Web app can request
http://169.254.169.254and reveal credentials: SSRF plus metadata service risk. - Storage bucket permits public read of confidential files: remove public access and review policy.
Test Your Knowledge
Changing /api/orders/100 to /api/orders/101 returns another customer order. Which weakness is most likely?
A
B
C
D
Test Your Knowledge
Which mitigation best prevents SQL injection in application code?
A
B
C
D
Test Your KnowledgeMulti-Select
Which controls directly reduce cloud key exposure risk? Select two.
Select all that apply
Secret scanning and alerting
Rotating leaked keys
Leaving keys in source control
Disabling audit logs