Cross-Site Scripting — Reflected, Stored, and DOM-Based

Cross-Site Scripting is injection aimed at the browser rather than the database. When an application places untrusted input into a page without properly encoding it, that input can be interpreted as HTML or JavaScript and executed in a victim's browser under the site's origin. The consequences range from stealing session tokens to rewriting the page and performing actions as the victim.

Analogy🏏Cricket

🍳 Think of it like cooking: A recipe can look flawless on paper, but a head chef only truly judges the dish by tasting the finished plate, because heat, timing, and the actual oven reveal problems the written method never shows. Just as tasting the cooked result catches what reading the recipe cannot, DAST probes the running application and catches the misconfigurations and runtime behaviour that reading the source cannot. This reveals DAST's stance: it judges the dish as it is actually served, not the recipe as it was merely written.

XSS comes in three flavours defined by where the untrusted data enters and where it lands: reflected, stored, and DOM-based. They share one root cause, data crossing into a code context without encoding, but they differ in delivery and persistence, which shapes both their impact and their fix. This lesson separates the three so the right defence is obvious for each.

Analogy🏏Cricket

💰 Think of it like finance: A real audit that actually attempts a sample transaction proves beyond doubt whether a control can be bypassed, with little room for a false alarm, but it can only test the accounts and processes the auditors actually reach. Just as a hands-on audit yields high-confidence, low-false-positive results yet is bounded by what it examines, DAST yields high-confidence findings about real exploitability yet is bounded by the surface it can reach. This reveals its trade-off: what it confirms is solid, but it only confirms what it manages to touch.