Application, API, and Cloud Attacks with Mitigation Mapping
Key Takeaways
- Application attacks exploit a failed control: input validation, output encoding, authorization, authentication, session protection, secret handling, or configuration.
- Injection sends untrusted input to an interpreter; cross-site scripting runs attacker-controlled script in a victim's browser.
- Broken access control covers IDOR, privilege escalation, and missing object-level authorization - the top web risk on current OWASP guidance.
- API attacks commonly target broken object-level authorization, excessive data exposure, mass assignment, and missing rate limits.
- Cloud attacks abuse misconfiguration, public storage, overly permissive IAM, instance metadata services, and leaked access keys.
Identify the Failed Control
For application and cloud questions, name the control that failed: input validation, output encoding, authorization, authentication, session protection, secret handling, or configuration management. The right mitigation almost always restores that specific control rather than bolting on a generic device.
Application Attack Map
| Attack | What the attacker does | Example clue | Primary mitigation |
|---|---|---|---|
| SQL injection | Alters database query logic via input | ' OR '1'='1 in a 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 |
| Cross-site scripting (XSS) | Runs script in another user's browser | Stored comment executes JavaScript | Output encoding, sanitization, Content Security Policy, HttpOnly cookies |
| Cross-site request forgery (CSRF) | Forces an authenticated browser to act | Hidden form submits a fund transfer | Anti-CSRF tokens, SameSite cookies, re-auth |
| Directory traversal | Reads files outside the web root | ../../etc/passwd | Canonicalize paths, allow-lists, least privilege |
| Server-side request forgery (SSRF) | Server makes attacker-chosen requests | App fetches 169.254.169.254 metadata | Egress filtering, metadata protections, URL allow-lists |
| Race condition (TOCTOU) | Timing gap changes the result | Coupon redeemed twice (double-spend) | Locking, atomic operations, idempotency keys |
| Insecure deserialization | Malicious object triggers code/logic | Tampered serialized token | Safe formats, signing, type validation |
| Buffer overflow | Input exceeds a memory boundary | Crash or code execution in native code | Memory-safe languages, bounds checks, DEP/ASLR |
Watch the XSS-versus-CSRF distinction: XSS executes attacker script in the victim's browser (a confidentiality/integrity problem on the client), while CSRF rides the victim's already-authenticated session to submit an action they did not intend. They are defended differently - encoding/CSP for XSS, tokens and SameSite cookies for CSRF.
API Attack Map
| API weakness | Scenario clue | Mitigation |
|---|---|---|
| Broken object-level authorization (IDOR) | /api/users/1001 changed to 1002 returns data | Authorize the principal for each object, every request |
| Excessive data exposure | API returns SSN even though the UI hides it | Return only required fields server-side |
| Mass assignment | Client adds "isAdmin": true to the JSON body | Bind only an allow-list of fields |
| Missing rate limits | Token endpoint hammered by bots | Per-user and per-IP throttling |
| Weak token handling | Long-lived bearer token in browser local storage | Short-lived scoped tokens, secure storage, rotation |
| Poor versioning | Old vulnerable API version stays exposed | Inventory, deprecate, enforce at the gateway |
Cloud Attack Map
The shared responsibility model is the lens here: the provider secures the cloud (hardware, hypervisor), but the customer secures in the cloud (data, IAM, network rules, OS patching). Most cloud breaches in this domain are customer misconfigurations.
| Cloud issue | Attack path | Mitigation |
|---|---|---|
| Public object storage | Anonymous users read sensitive files | Block public access, review bucket policy |
| Overly permissive IAM | One compromised user administers the account | Least privilege, permission boundaries, access reviews |
| Leaked access key | A key in a repo or image is reused externally | Secret scanning, rotation, workload identity |
| Metadata service abuse | SSRF retrieves temporary instance credentials | IMDSv2, egress allow-lists, fix the SSRF |
| Open security group | Management port (e.g., 22/3389) exposed to the internet | Restrict source, VPN/bastion, just-in-time access |
| Insecure container image | Known-vulnerable package ships to production | Image scanning, patching, signed images |
| Misconfigured logging | Attack leaves little trace | Enable audit logs, centralize, protect retention |
Mitigation Selection Worked Example
An authenticated user requests /api/invoices/8571. Changing the ID to 8572 returns another customer's invoice. This is broken object-level authorization (IDOR) - not SQL injection, because no database syntax is being injected. The only real fix is to verify, on every request, that the authenticated principal is authorized for the requested object.
| Wrong fix | Why it is incomplete |
|---|---|
| Hide invoice IDs in the UI | Attackers still tamper with the raw request |
| Encrypt transport with TLS | TLS protects data in transit but enforces no authorization |
| Add a WAF only | A WAF cannot reliably know business ownership of an object |
| Rename the endpoint | Security through obscurity does not add authorization |
Common Traps
| Trap | Better exam reasoning |
|---|---|
| Injection versus IDOR | Injection alters interpreter commands; IDOR bypasses object authorization |
| WAF as the only answer | A WAF is compensating; fix the code or configuration when possible |
| Blame the cloud provider for IAM mistakes | Customer identity and configuration are the customer's responsibility |
| Treat SSRF as harmless | SSRF can reach the metadata service and steal cloud credentials |
Quick Drill
(1) User input lands directly in a SQL WHERE clause - parameterized queries. (2) An API returns another user's record after only an ID change - enforce object-level authorization. (3) An app can fetch http://169.254.169.254 and reveal credentials - SSRF plus metadata-service risk; use IMDSv2 and egress filtering. (4) A storage bucket allows public read of confidential files - block public access and review the policy.
Changing /api/orders/100 to /api/orders/101 returns another customer's order. Which weakness is most likely?
Which mitigation most directly prevents SQL injection in application code?
Which controls directly reduce cloud access-key exposure risk? Select two.
Select all that apply