Why Application Security Matters
Applications are now the most common attack surface in organizations. The network perimeter has shrunk while web applications, APIs, and cloud-native services have exploded in number. According to breach data, the majority of successful attacks target the application layer — not the network. The Security+ exam covers application security across multiple domains, particularly Domain 2 (Threats and Vulnerabilities) and Domain 3 (Security Architecture).
Application security (AppSec) means building and maintaining software in a way that protects it against threats. It encompasses secure development practices, vulnerability testing, code review, and runtime protection. The most important framework for understanding common web application vulnerabilities is the OWASP Top 10.
OWASP Top 10 (2021)
OWASP (Open Worldwide Application Security Project) publishes the Top 10 Web Application Security Risks — a consensus list of the most critical vulnerabilities, updated based on real-world breach data. The current version is from 2021.
' OR '1'='1 to bypass login. Fix: parameterized queries/prepared statements, input validation.SQL Injection Deep Dive
SQL injection (SQLi) is consistently one of the most tested application security topics on Security+. It occurs when an application builds SQL queries by concatenating user input without sanitization, allowing an attacker to inject their own SQL commands.
Vulnerable query: SELECT * FROM users WHERE username='input' AND password='input'
Attacker enters: ' OR '1'='1' -- as the username.
Resulting query: SELECT * FROM users WHERE username='' OR '1'='1' --' AND password='x'
The -- comments out the rest, and '1'='1' is always true — the attacker bypasses authentication entirely without knowing any credentials.
Defenses against SQL injection: The primary fix is parameterized queries (also called prepared statements) — the query structure is defined separately from the data, so user input can never be interpreted as SQL commands. Secondary defenses include input validation, stored procedures, and least-privilege database accounts.
Cross-Site Scripting (XSS)
XSS occurs when an application includes unvalidated, unsanitized user input in its web page output, allowing attackers to inject client-side scripts that execute in other users' browsers. There are three types:
| XSS Type | How It Works | Persistence |
|---|---|---|
| Stored (Persistent) | Malicious script is saved in the database and served to every user who views the affected page — e.g., script in a comment field | Persistent — affects all users until removed |
| Reflected (Non-persistent) | Malicious script is in the URL — attacker tricks victim into clicking a crafted link; script reflects off the server and runs in victim's browser | One-time per link click |
| DOM-Based | Vulnerability is in client-side JavaScript — browser modifies DOM based on user-controlled input without sending data to the server | Client-side only; no server interaction |
Defenses against XSS: Output encoding (HTML-encode user-supplied data before rendering), Content Security Policy (CSP) headers that restrict which scripts can execute, and input validation. The key insight: it's about encoding output, not just validating input.
Cross-Site Request Forgery (CSRF)
CSRF tricks an authenticated user's browser into making a request to a web application they're already logged into — without their knowledge. If a user is logged into their bank, a malicious page can load an invisible image whose URL is a bank transfer request. The browser automatically includes the session cookie, and the bank executes the transfer.
XSS: Attacker injects scripts that run in the victim's browser — attacker exploits the user's trust in the website.
CSRF: Attacker tricks the victim's browser into making requests — exploits the website's trust in the user's browser.
Primary defense for CSRF: Anti-CSRF tokens (unique, unpredictable tokens included in forms and validated server-side). SameSite cookie attribute also helps significantly.
Secure Software Development Lifecycle (SDLC)
The Secure SDLC integrates security activities into every phase of software development — rather than bolting security on at the end. The Security+ exam tests which activities happen in which phase.
| SDLC Phase | Security Activities |
|---|---|
| Planning / Requirements | Define security requirements; identify regulatory compliance needs; establish security acceptance criteria |
| Design | Threat modeling (STRIDE, PASTA); security architecture review; define trust boundaries; data flow analysis |
| Development / Coding | Secure coding standards; code review; static analysis (SAST); developer security training |
| Testing / QA | Dynamic analysis (DAST); penetration testing; vulnerability scanning; fuzzing; security regression testing |
| Deployment | Secure configuration; change management; infrastructure hardening; secrets management |
| Maintenance / Operations | Patch management; continuous monitoring; incident response; security updates for dependencies |
Code Analysis Techniques
SAST: analyzes code without running it — finds issues early (shift left), but can't find runtime issues. Used by developers during coding.
DAST: tests the running application — finds runtime issues (authentication, session management) but can't see source code. Used by testers and security teams.
IAST (Interactive AST) = hybrid that instruments the running app and analyzes from inside — you may see this as a distractor on the exam.
Input Validation
Input validation is the practice of ensuring that all input received by an application conforms to expected format, type, length, and range before it's processed. It's the foundational defense against injection attacks, buffer overflows, and many other vulnerabilities.
| Technique | What It Does | Example |
|---|---|---|
| Allowlist (Whitelist) | Only permit known-good values; reject everything else | Phone number field only accepts digits and hyphens — letters rejected |
| Denylist (Blacklist) | Reject known-bad values; allow everything else | Block <script> tags in input — weaker than allowlisting |
| Type checking | Ensure input matches expected data type | Age field must be an integer; reject strings |
| Length/range checks | Ensure input within expected bounds | Zip code: exactly 5 digits; reject longer values |
| Parameterized queries | Separate code from data — data can never be interpreted as SQL | Use ? placeholders in SQL statements, pass values separately |
| Output encoding | Encode data before rendering to prevent script injection | Convert < to < before displaying user content in HTML |