Secure Coding and Application Mitigations

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

Secure Coding and Application Mitigations

Key Takeaways Explain This Topic AI

Secure coding prevents vulnerability classes before deployment through input handling, output encoding, authentication, and authorization.

Parameterized queries, allow-list validation, output encoding, and safe error handling map directly to OWASP-style web risks tested on SY0-701.

SAST, DAST, IAST, SCA, fuzzing, and secrets scanning each find a different class of weakness.

Apply mitigations as close to the root cause as possible; WAF and RASP are useful but usually compensating controls.

A secure SDLC adds threat modeling, security requirements, testing gates, and dependency governance at each phase.

Last updated: June 2026

Fix the Class, Not Just the Symptom

Secure-coding questions on SY0-701 ask for the control that prevents a vulnerability class , not one that merely detects attacks after release. The strongest answer is normally the one closest to the root cause; perimeter tools like a WAF (web application firewall) buy time but do not fix the code.

Mitigation Mapping

• Weakness Best mitigation Why it works
• SQL injection Parameterized queries (prepared statements) Separates data from SQL command structure
• Command injection Avoid shell calls; use allow lists Removes interpreter abuse path
• Cross-site scripting (XSS) Context-aware output encoding and sanitization Prevents untrusted script execution
• Cross-site request forgery (CSRF) Anti-CSRF token plus SameSite cookies Confirms request intent
• Insecure direct object reference (IDOR) Object-level authorization checks Enforces ownership on every object
• Path traversal Canonicalize paths and use allow lists Blocks escaping the intended directory
• Hardcoded secrets Secret manager and rotation Removes secrets from code and images
• Verbose errors Generic user errors, detailed server logs Reduces information disclosure
• Insecure file upload Type validation, scanning, storage isolation Limits malicious file execution
• Race condition (TOCTOU) Locking, atomic operations, idempotency Prevents timing-based logic abuse

The most common trap pairs XSS with "input validation only." Input validation helps, but output encoding is central because the same data is dangerous in HTML, attribute, JavaScript, and URL contexts differently, and encoding is applied where the data is rendered.

Two defensive habits underpin most of the table. Allow-list (whitelist) validation accepts only known-good input and rejects everything else; it is far stronger than deny-list (blacklist) filtering, which tries to enumerate bad input and always misses a new bypass. And the principle of least privilege applied to service and database accounts limits the damage when a flaw slips through, which is why least-privilege accounts appear as a secondary control beside the primary code fix.

Testing and Review Methods

Each tool finds a different class. Match the tool to what the stem describes.

• Method Best at finding When used
• Threat modeling Design weaknesses and trust-boundary gaps Before/during design
• Secure code review Logic flaws and risky patterns During development
• SAST (static analysis) Source-level issues without running code CI pipeline or developer IDE
• DAST (dynamic analysis) Runtime web behavior, no source needed Test or staging environment
• IAST (interactive) Runtime issues with code-level context Instrumented test runs
• SCA Vulnerable dependencies and license risk Build and dependency updates
• Fuzzing Crashes and bad-input handling Parsers, APIs, native components
• Secrets scanning Exposed keys and credentials Commit, build, registry checks

Know the SAST-versus-DAST distinction cold: SAST reads source code early and pinpoints the vulnerable line but produces false positives; DAST attacks the running app like an outsider, so it confirms exploitability but cannot point to the exact code.

Worked Example: Fix the Root Cause

A developer builds a query by concatenating user input: SELECT * FROM accounts WHERE owner = '$user' AND status = 'active'

Escaping input reduces some risk, but parameterized queries are the stronger answer because the database receives the command structure separately from the value, so injected SQL is treated as literal data. Least-privilege database accounts reduce blast radius if another flaw exists, but they do not replace secure query construction. A WAF can block obvious payloads temporarily; it is a compensating control, not the fix.

Secure SDLC Controls

Security belongs at every phase of the software development lifecycle (SDLC) , not bolted on at the end.

• SDLC phase Security activity
• Requirements Define authentication, logging, privacy, data-protection needs
• Design Threat-model data flows and trust boundaries
• Development Secure-coding standards, code review, secrets scanning
• Build SAST, SCA, signed artifacts
• Test DAST, fuzzing, abuse-case testing
• Deploy Hardened config, secure secret injection
• Operate Monitoring, vulnerability management, incident feedback

Two deployment-side controls round out the picture. Code signing proves an artifact came from a trusted publisher and was not altered after build, so consumers can reject tampered binaries. Input sanitization at trust boundaries plus secure default configurations (fail closed, no debug endpoints in production) prevent a hardened codebase from being undone by a careless release. The exam treats the SDLC as a chain: a flawless code review means little if the build pulls an unsigned dependency or the deploy step injects a secret into a logged environment variable.

Common Traps

• Trap Better exam reasoning
• "Validate input" as the only XSS control Output encoding is central because context matters
• WAF as a permanent code-fix replacement WAF reduces exposure while code is fixed
• Hiding buttons to enforce authorization Server-side authorization must enforce access
• Logging full secrets for debugging Logs must never expose passwords or tokens
• Quick Drill

Choose the most direct mitigation:

A user-controlled search value changes SQL results unexpectedly: parameterized query.

A user edits JSON to add "role":"admin" : allow-list bindable fields and enforce server-side authorization (mass-assignment).

An error page reveals a stack trace and database path: generic user error, detailed protected server log.

An API accepts a duplicate payment confirmation twice: idempotency key or atomic transaction handling.

A comment field stores <script> that runs for later viewers: context-aware output encoding (stored XSS).