Content Security Policy and Output Encoding

Output encoding prevents XSS by ensuring untrusted data is rendered as text, and Content Security Policy (CSP) limits the damage if a payload ever slips through. They are complementary layers: encoding tries to stop injection from happening, while CSP assumes something might and constrains what injected code is allowed to do. Neither replaces the other, and strong applications use both.

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.

This lesson treats them as a pair. First it revisits why encoding must be contextual, matched to where data lands in the page. Then it introduces CSP as a browser-enforced allowlist that can block inline scripts and unauthorised sources, turning an otherwise successful XSS into a neutralised one. The aim is defence in depth: prevent what you can, contain what you cannot.

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.