CompTIA SY0-701: Application & Web Security — Study Guide
Part of the CompTIA Security+ SY0-701 — Complete Study Guide. Practice with verified answers in the CompTIA exam hub, or take timed practice tests on ExamRoll.io.
Modern applications sit at the intersection of business logic, sensitive data, and untrusted user input. Because web and mobile front ends are exposed to the entire internet, they represent one of the largest and most consistently exploited attack surfaces in any enterprise. Defending them requires layered controls that begin with the way code is written and extend through runtime protections, integrity verification, and continuous testing.
Injection Attacks
Injection remains the archetypal web vulnerability. It occurs whenever an application concatenates untrusted input into an interpreter — a SQL query, a shell command, an LDAP filter, an XML parser, or a template engine — without properly separating code from data. In a SQL injection (SQLi), an attacker manipulates a query so that the database executes attacker-controlled logic. A classic vulnerable pattern in PHP looks like this:
$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";
Submitting admin' OR '1'='1 transforms the query into a tautology that returns every row. More advanced variants include union-based extraction (' UNION SELECT credit_card FROM payments--), blind Boolean or time-based inference (' AND SLEEP(5)--), and out-of-band exfiltration through DNS callbacks. The definitive fix is parameterized queries or prepared statements, which send the query template and its parameters to the database as separate structures:
cursor.execute("SELECT * FROM users WHERE username = %s", (user_input,))
Command injection follows the same pattern but targets the operating system shell. Code like os.system("ping " + host) allows an attacker to submit 8.8.8.8; cat /etc/passwd and execute arbitrary commands. Remediation requires avoiding shell invocation entirely, using APIs that accept argument arrays (subprocess.run(["ping", host], shell=False)), and applying strict allow-list validation to any value that must reach a shell.
Cross-Site Scripting and CSRF
Cross-site scripting (XSS) is the injection of malicious script into pages rendered by a trusted application, causing the victim’s browser to execute attacker code within the site’s origin. Reflected XSS bounces payloads off a vulnerable parameter; stored XSS persists the payload in the database and delivers it to every viewer; DOM-based XSS occurs entirely in client-side JavaScript that writes untrusted data into innerHTML, document.write, or similar sinks. Consequences range from session hijacking and keylogging to full account takeover through forced actions.
Cross-site request forgery (CSRF) is a distinct but complementary attack. It abuses the browser’s automatic inclusion of cookies to trick an authenticated user into submitting an unwanted request — for example, a hidden form on a malicious site that POSTs to bank.com/transfer. Defenses include synchronizer tokens (random per-session values embedded in forms and verified server-side), the SameSite=Lax or SameSite=Strict cookie attribute, and requiring re-authentication for sensitive actions. XSS and CSRF are often conflated, but XSS runs code in the victim’s browser while CSRF simply causes the browser to issue a request; notably, a successful XSS attack can defeat most CSRF defenses.
Secure Coding: Input Validation vs. Output Encoding
Two controls are frequently confused, yet they solve different problems. Input validation ensures data conforms to expected structure — length, type, character set, range, format — before the application acts on it. It should happen on the server, using allow-lists whenever possible (^[A-Za-z0-9_]{3,20}$ for a username). Client-side validation using JavaScript is a usability feature only; it can be bypassed with any HTTP proxy and must never be the security boundary.
Output encoding ensures that data is rendered safely in whatever context it flows into. The same string that is perfectly valid input may need different treatment depending on where it lands: HTML body context requires HTML entity encoding (< → <), attribute context requires quoted attribute encoding, JavaScript context requires \xHH escaping, and URLs require percent-encoding. A username like O'Brien is legitimate input but must be encoded as O'Brien when placed into HTML. Input validation cannot replace output encoding, and encoding cannot replace validation — they address different problems at different points in the data lifecycle.
Additional hardening includes Content Security Policy (CSP) headers to restrict script sources, HttpOnly and Secure flags on session cookies, and parameterized APIs at every trust boundary.
WAFs and File-Upload Protections
A web application firewall inspects HTTP traffic and blocks requests matching known malicious patterns — SQLi signatures, XSS payloads, path traversal sequences, protocol anomalies. Deployed as a reverse proxy (ModSecurity with the OWASP Core Rule Set, AWS WAF, Cloudflare, F5), it provides valuable virtual patching when a vulnerability is discovered before code can be fixed. However, a WAF is a compensating control, not a substitute for secure coding. Sophisticated attackers routinely bypass WAFs through encoding tricks, HTTP parameter pollution, and payload fragmentation.
File uploads deserve special attention because they combine untrusted content with server-side storage and, often, execution. Protections include validating the file type by inspecting magic bytes rather than trusting the extension or Content-Type header, storing uploads outside the web root, renaming files to server-generated identifiers (preventing directory traversal via crafted filenames), scanning with antivirus before storage, and serving user-uploaded content from a separate domain to prevent same-origin script execution.
Practical Scenario: SQL Injection Leading to Full Database Compromise
A retail company’s product search endpoint accepted a category parameter that was concatenated directly into a SQL query without sanitization. A security researcher discovered that submitting ' UNION SELECT table_name,null,null FROM information_schema.tables-- returned a list of all database tables in the response. Subsequent requests extracted the customers table, yielding 1.2 million records including names, email addresses, and bcrypt-hashed passwords. The attacker also discovered a stored procedure that could be invoked via SQL injection to write files to the web root, enabling webshell deployment and full server compromise. The vulnerability had been present for three years and had been missed in two prior penetration tests because the testers had only tested the login form, not the search endpoint. The lesson: injection testing must cover every parameter in every endpoint, not just the obvious authentication paths.
← Incident Response · All domains · Cloud →
Practice these questions → · Timed practice on ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Pass your exam →