ExamFinch.com My Study

Study guide

Application, API, and Cloud Attacks with Mitigation Mapping

Practice this exam

CompTIA Security+ SY0-701

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

Current Exam Facts and How Security+ Tests Judgment Domain Weighting and an 8-12 Week Study Plan Practice Questions, PBQs, and the Missed-Question Notebook

2 Domain 1: General Security Concepts (12%)

CIA and Non-Repudiation Control Types and Categories with Scenario Classification Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust Change Management and Business Impact

3 Domain 1: Identity, Trust, and Cryptography Basics

AAA and IAM Concepts Authentication Factors and MFA Traps Authorization Models: RBAC, ABAC, MAC, DAC, and Least Privilege Cryptography, Hashes, Signatures, PKI, and Certificate Decision Rules

4 Domain 2: Threat Actors, Vectors, and Social Engineering

Threat Actors and Motivations Attack Vectors and Attack Surface Social Engineering Types and Clues Supply Chain and Insider Threat Scenarios

5 Domain 2: Threats, Vulnerabilities, and Mitigations - Attacks

Malware Behaviors and Indicators Credential and Password Attacks Network and Wireless Attacks Application, API, and Cloud Attacks with Mitigation Mapping

6 Domain 2: Threats, Vulnerabilities, and Mitigations - Vulnerabilities

Vulnerability Types and Misconfiguration Vulnerability Scanning and Prioritization Secure Coding and Application Mitigations Remediation, Compensating Controls, and Risk-Based Decisions

7 Domain 3: Security Architecture - Secure Architecture Models

Architecture Models and Trust Boundaries Cloud Shared Responsibility and Service Models Zero Trust, SASE, and SSE Concepts Secure Design Review Scenarios

8 Domain 3: Security Architecture - Network Security Architecture

Segmentation, VLANs, DMZ, and Microsegmentation Firewalls, WAF, IDS, IPS, and Proxies VPN, Remote Access, and NAC Wireless Security and Enterprise Network Design

9 Domain 3 Part C: Data Protection and Resilience

Data Classification and Handling Encryption at Rest, in Transit, in Use, and Key Management DLP, Privacy, and the Data Lifecycle Backups, RTO, RPO, BCP, DR, and Resilience

10 Domain 4 Part A: Secure Operations for Hosts, Cloud, Mobile, and IoT

Endpoint and Server Hardening Cloud, Container, and Virtualization Operations Mobile, BYOD, and MDM Embedded, IoT, OT, and Physical Device Security

11 IAM Operations and Access Control

Provisioning, Deprovisioning, and Access Reviews PAM, JIT, JEA, and Service Accounts Federation, SSO, SAML, OIDC, and OAuth Account Attacks and IAM Monitoring

12 Logging, Monitoring, and Detection

Log Sources and Telemetry SIEM Correlation and Alert Triage SOAR, Playbooks, and Automation Detection Use Cases and False-Positive Handling

13 Incident Response

IR Phases and Roles Containment, Eradication, and Recovery Decisions Communication, Escalation, Legal, and Regulatory Considerations Post-Incident Lessons Learned and Metrics

14 Digital Forensics and Investigation

Evidence Handling and Chain of Custody Disk, Memory, Network, and Log Artifacts Order of Volatility and Acquisition Choices Forensic Reporting and Anti-Forensics Traps

15 Vulnerability, Patch, Asset, and Automation Operations

Asset Inventory and Data Classification in Ops Vulnerability Lifecycle and CVSS/Risk Priority Patch, Change, and Configuration Management Automation, Orchestration, SCAP, and Security Tooling

16 Governance, Policies, and Risk Management

Governance Documents: Policy, Standard, Procedure, and Baseline Risk Register and Risk Treatment Quantitative/Qualitative Risk and BIA Exceptions, Acceptance, Ownership, and Reporting

17 Third-Party Risk, Compliance, and Privacy

Vendor Risk Lifecycle and Agreements Due Diligence, Questionnaires, and Monitoring Privacy Concepts and Data Rights Compliance Reporting and Consequences

18 Audits, Penetration Testing, and Awareness

Internal and External Audits and Evidence Penetration Test Types and Rules of Engagement Security Awareness, Training, and Phishing Metrics Personnel and Physical Security Program Controls

19 Final Review and PBQ Labs

PBQ Workflow and Timing Ports, Protocols, and Acronyms High-Yield Tables Firewall, IAM, Log, and Risk PBQ Mini-Labs Final 7-Day Review Plan Mixed Exam Strategy and Missed-Question Remediation

Application, API, and Cloud Attacks with Mitigation Mapping

Key Takeaways Explain This Topic AI

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.

Last updated: June 2026

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.