15.1.1 — Learning Objectives

By the end of this lesson you will be able to:

• Identify the three categories of application and data vulnerabilities: injection, authentication & access, and data exposure.
• Map any described attack to its OWASP Top 10 category.
• Trace how SQL injection, XSS, and broken authentication actually execute, step by step.
• Distinguish application vulnerabilities from data vulnerabilities and explain how they chain together in real breaches.
• Recommend the correct control for each category of vulnerability.
• Analyze real-world breach scenarios (Equifax, Target, Capital One) and identify which OWASP category was exploited.

25.1.2 — Why Applications Are the #1 Attack Vector

Units 1 through 4 of this course built a mental model: attackers target people (Unit 1), physical spaces (Unit 2), networks (Unit 3), and devices (Unit 4). Unit 5 goes to the final frontier — the applications and data those earlier controls protect.

Here is the uncomfortable reality that drives this entire unit: even if a company deploys every control from Units 1–4 perfectly — the best MFA, the best firewalls, the best hardened servers — a single vulnerable web application can hand an attacker everything. Applications are exposed to the Internet by design. They must accept untrusted input. They hold the data attackers actually want.

Why Applications Expose So Much Attack Surface

The Three Categories You Must Know Cold

Every application and data vulnerability on the AP Cyber exam falls into one of three buckets. Memorize these three — they are the lens through which you will classify every scenario in the unit.

35.1.3 — Essential Vocabulary & Exam Tips

The exam rewards students who can translate a plain-English attack description into the exact technical term. Learn these definitions as matched pairs — what the term means and what the exam calls it.

45.1.4 — The OWASP Top 10 Framework

The Open Web Application Security Project maintains the industry's canonical list of the most critical web application security risks. The AP Cyber exam uses this framework implicitly — every Unit 5 application-security question maps to an OWASP category.

You do not need to memorize OWASP numbering (A01, A02, etc.) for the AP exam. You do need to recognize each category by its description and map real scenarios to the right one.

The OWASP Top 10 (2021 edition) — AP Cyber Exam Priority

Rows in purple are the four categories that appear most often on AP Cyber exam questions. If you are tight on study time, prioritize these.

55.1.5 — Injection Attacks: How SQLi & XSS Actually Work

Injection is the single most tested application vulnerability on AP Cyber. The exam does not expect you to write injection payloads, but it absolutely expects you to trace why a given payload works.

The Universal Pattern of Injection

Every injection attack in history follows the same three-step pattern:

1. The application receives untrusted input (form field, URL parameter, header, uploaded file).
2. The application combines that input with code meant to be interpreted later (SQL query, HTML page, shell command).
3. The interpreter cannot tell the difference between the developer's code and the attacker's input. The interpreter runs everything as instructions.

If you can recite this three-step pattern on the exam, you can solve any injection question.

SQL Injection: A Real Login Form

Suppose a developer writes this login code (conceptual Python):

query = "SELECT * FROM users WHERE username = '" + input_user + "' AND password = '" + input_pass + "'"
database.execute(query)

When the user types alice and hunter2, the query becomes:

SELECT * FROM users WHERE username = 'alice' AND password = 'hunter2'

Exactly what the developer intended. Now watch what happens when an attacker types ' OR '1'='1 in the password field:

SELECT * FROM users WHERE username = 'alice' AND password = '' OR '1'='1'

The query now says: return rows where the password is empty OR where 1 equals 1. Since 1 always equals 1, the query returns every row. The attacker is logged in as the first user in the database — often the admin.

The Fix: Parameterized Queries

The defense is not to filter special characters — that is a losing game. The defense is to structurally separate code from data. A parameterized query looks like this:

query = "SELECT * FROM users WHERE username = ? AND password = ?"
database.execute(query, [input_user, input_pass])

The ? placeholders tell the database driver: these are data, not code. No matter what is in them, do not interpret them as SQL. An attacker typing ' OR '1'='1 now just searches for a literal password that contains those characters, finds nothing, and is rejected.

Cross-Site Scripting (XSS): Injection into HTML

XSS is the same three-step pattern, but the interpreter is the browser and the injected code is JavaScript.

Suppose a comment section displays user comments like this:

[user comment here]

If the application does not encode output, an attacker can submit this "comment":

Every future visitor who views that comment has their session cookie sent to the attacker. The attacker now impersonates those users without knowing their passwords.

Injection Variants You Should Recognize

65.1.6 — Broken Authentication & Session Failures

Authentication is the system that answers the question: are you actually who you say you are? Broken authentication is any failure of that system. On the AP exam, broken authentication usually shows up as one of four patterns.

Pattern 1: Weak Password Policies

The application allows short passwords, common passwords, or reused breached passwords. Attackers use credential stuffing (trying leaked username/password pairs from other breaches) or dictionary attacks (trying common passwords).

The defense isn't "require special characters." Modern guidance (NIST SP 800-63B) says password length is what matters, combined with checking against known-breached passwords. Special character requirements actually push users toward predictable patterns like Password1!.

Pattern 2: Session Token Problems

When you log in, the server gives your browser a session token (a random string stored as a cookie). Every subsequent request sends that token as proof of identity. If the token is stolen, guessed, or reused, an attacker is logged in as you — no password needed.

Pattern 3: Missing or Weak MFA

Multi-factor authentication (MFA) requires something the user knows (password) plus something they have (phone, token, security key) or something they are (fingerprint). Skipping MFA on the grounds that "it is inconvenient" is the single most common broken-authentication failure in breach post-mortems.

Not all MFA is equal. SMS codes can be intercepted by SIM-swap attacks. Authenticator apps (TOTP) are better. Hardware security keys (FIDO2) are strongest.

Pattern 4: Credential Recovery Flows

Password reset flows are frequently weaker than the login flow itself. If "forgot password" sends a link valid for 7 days, stored in an unencrypted email, and allows the attacker to set any new password without confirming identity, the password itself never mattered.

75.1.7 — Sensitive Data Exposure: Storage & Transit

Sensitive data exposure (OWASP now calls it "Cryptographic Failures") covers every way that confidential data can be revealed because it was not protected adequately. Two contexts matter: data at rest (storage) and data in transit (network).

Data At Rest: What Went Wrong

Data In Transit: What Went Wrong

Data moving between client and server is exposed to every network between them. If the data is not encrypted in transit, anyone on those networks can read and modify it.

• HTTP instead of HTTPS. Anyone on public Wi-Fi, in an ISP, or on the corporate network can read unencrypted HTTP traffic. There is no modern justification for HTTP on an authenticated application.
• Outdated TLS versions. TLS 1.0 and 1.1 have known vulnerabilities. Current baseline is TLS 1.2; TLS 1.3 is preferred. Deprecated protocols must be disabled on the server.
• Weak cipher suites. Even with TLS enabled, servers can be configured to accept weak ciphers (RC4, DES). Attackers can force a downgrade negotiation.
• Missing certificate validation. If the client does not verify the server's certificate, a man-in-the-middle can present their own certificate and decrypt traffic.

85.1.8 — Real Breach Case Studies

Every category you just studied shows up in real breaches that made headlines. Walking through each of these helps lock in which OWASP category the AP exam is testing when similar scenarios appear.

Case 1: Equifax (2017) — 147 Million Records

Case 2: Heartland Payment Systems (2008) — 134 Million Card Numbers

Case 3: Target (2013) — 40 Million Card Numbers

Case 4: Capital One (2019) — 100 Million Records

Case 5: Yahoo (2013–2014, disclosed 2016) — 3 Billion Accounts

95.1.9 — Worked Examples: Predict First, Then Classify

The exam rewards students who classify before they read options. For each of these worked examples, cover the answer, commit to your category, then compare.

105.1.10 — AP Exam Strategy: Application & Data Security Questions

Unit 5 questions on the AP Cyber exam tend to follow predictable patterns. If you recognize the pattern, you can solve the question before reading all four options — which is exactly the "predict first" method that separates 5-scorers from 3-scorers.

The Three-Question Triage

For any application-security scenario on the exam, run through these three questions in order:

1. Was untrusted input interpreted as code? If yes → Injection.
2. Did the attacker get in without valid credentials, or act as someone they are not? If they got in with no password → Broken Authentication. If they got in as themselves but did things they shouldn't → Broken Access Control.
3. Was data revealed because of how it was stored, transmitted, or logged? If yes → Sensitive Data Exposure / Cryptographic Failures.

Pattern-Match Language the Exam Uses

Common Distractor Traps

?5.1.11 — Frequently Asked Questions

+ Continue Learning