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?
Broken object-level authorization
DNS poisoning
Jamming
Key stretching
Which mitigation most directly prevents SQL injection in application code?
Longer DHCP lease times
Open Wi-Fi isolation
Parameterized queries
A public bucket policy
Which controls directly reduce cloud access-key exposure risk? Select two.
Select all that apply
Secret scanning and alerting
Rotating leaked keys promptly
Leaving keys in source control
Disabling audit logs
Sections you finish are checked off in the contents.