XSS

XSS (cross-site scripting) is an application attack where an adversary injects malicious script, usually JavaScript, into a web page so it runs in another user's browser, exploiting missing input checks to steal session tokens, credentials, or other sensitive data.

What is XSS?

XSS stands for cross-site scripting. It's a web application attack where an attacker sneaks malicious code, almost always JavaScript, into a page that other people view. When a victim's browser loads that page, it runs the attacker's script as if the site itself wrote it. From there the script can read whatever the browser has access to, like stored session tokens or login credentials.

Why does it work? Web applications run on a server and take input from users through open-ended fields and links (EK 5.1.B.1, EK 5.1.B.2). If the developer doesn't check that input, an attacker can type in a script instead of a normal value, and the app happily stores it or reflects it back into the page. The browser can't tell the difference between code the developer meant to send and code the attacker slipped in. That missing check, the failure to verify that user input matches what's expected, is the core vulnerability behind XSS.

Why XSS matters in AP Cybersecurity

XSS lives in Unit 5, Topic 5.1 (Application and Data Vulnerabilities and Attacks), and it's a textbook example of objective AP Cybersecurity 5.1.B: explaining how application attacks exploit vulnerabilities. It also ties directly to AP Cybersecurity 5.1.C, because a successful XSS attack hits the CIA triad. Stolen session tokens break confidentiality, and a script that alters page content breaks integrity (EK 5.1.C.1). Understanding XSS shows you grasp the bigger pattern the CED keeps hammering: when an app trusts user input it shouldn't, attackers turn that trust into a weapon.

How XSS connects across the course

Input validation and sanitization (Unit 5)

XSS is what happens when these defenses are missing. Input validation checks that input matches expected criteria, and sanitization strips or neutralizes dangerous characters so a typed-in script never executes. The fix for XSS is literally these two controls done right.

Injection-type attacks (Unit 5)

XSS belongs to the injection family, alongside SQL injection. The shared idea is that an attacker inserts code into an input field, and the app runs it. XSS injects script that runs in the browser, while SQL injection injects commands that run against the database.

Session tokens and data in use (Unit 5)

The classic XSS payload steals session tokens sitting in browser storage. Those tokens are data in use, active in the browser, which is why a script running there can grab them and impersonate the victim.

Is XSS on the AP Cybersecurity exam?

Expect XSS to show up in scenario-based multiple-choice stems. A common version describes a user clicking a link with hidden JavaScript that runs in their browser and steals stored session tokens or credentials, then asks which attack type that is. The answer is XSS (cross-site scripting). You'll also see it grouped with SQL injection under "which of the following is an injection-type attack." To get these right, recognize two signals: code running in a victim's browser, and the root cause being an app that didn't check user input. Be ready to name input validation or sanitization as the defense.

XSS vs SQL injection

Both are injection attacks that exploit missing input checks, but the target differs. XSS injects script that runs in another user's browser to steal things like session tokens. SQL injection injects database commands that run on the server to read or alter stored data. If the scenario mentions a browser executing JavaScript, it's XSS; if it mentions querying or dumping a database, it's SQL injection.

Key things to remember about XSS

• XSS (cross-site scripting) injects malicious script, usually JavaScript, into a web page so it runs in a victim's browser.

• The root cause is missing input validation, the app fails to check that user input matches what's expected (EK 5.1.B.2).

• A typical XSS payload steals session tokens or credentials from browser storage, breaking confidentiality.

• XSS is an injection-type attack, in the same family as SQL injection, but it runs in the browser rather than against a database.

• The defense is input validation and sanitization, neutralizing dangerous input before the browser ever executes it.

Frequently asked questions about XSS

What is XSS in AP Cybersecurity?

XSS, or cross-site scripting, is a web application attack where an adversary injects malicious script into a page so it runs in another user's browser. It maps to Topic 5.1 and supports learning objective AP Cybersecurity 5.1.B on how application attacks exploit vulnerabilities.

Is XSS an injection attack?

Yes. XSS is a type of injection attack because the attacker inserts code into an input field and the application runs it. The difference is that XSS injects script that executes in the browser, while SQL injection injects commands that run against a database.

How is XSS different from SQL injection?

Both exploit missing input checks, but XSS targets the browser and SQL injection targets the database. If a question describes a victim's browser executing JavaScript to steal session tokens, it's XSS; if it describes manipulating or reading a database, it's SQL injection.

What does an XSS attack steal?

Often session tokens or authentication credentials stored in the browser. With a stolen session token, an attacker can impersonate the victim, which is a direct compromise of confidentiality under EK 5.1.C.1.

How do you prevent XSS?

Use input validation and input sanitization so the application checks and cleans user input before it ever reaches the page. If the app verifies that input matches expected criteria and strips dangerous characters, an injected script never gets to execute.