TOPIC OVERVIEW

javascript/Security

The common ways JavaScript applications get exploited — and how to prevent it.

10 QuestionsAdvancedHigh Priority ~13 min read

Most client-side JavaScript security issues come down to trusting data that shouldn't be trusted. Cross-Site Scripting (XSS) happens when unsanitized user input gets rendered as HTML or executed as script — directly setting innerHTML with user content is the classic mistake, which is why frameworks like React escape content by default and why dangerouslySetInnerHTML is named the way it is. Cross-Site Request Forgery (CSRF) is a different problem: a malicious site tricks a logged-in user's browser into making a request to your app, relying on cookies being sent automatically.

Defenses map directly to these threats. Content Security Policy (CSP) headers restrict what scripts are allowed to run and from where, meaningfully limiting the damage even if an XSS injection succeeds. CSRF tokens and the SameSite cookie attribute prevent forged cross-site requests from being honored. The Same-Origin Policy underlies most of this — it's the browser's default rule that scripts from one origin can't read data from another, and CORS is the controlled, opt-in mechanism for relaxing that rule when it's actually needed.

What you'll walk away knowing

What XSS is, the difference between stored/reflected/DOM-based variants, and how sanitization prevents it

How CSRF attacks work, and what CSRF tokens and SameSite cookies actually protect against

What Content Security Policy does, and how it limits damage even after a successful injection

How the Same-Origin Policy and CORS relate — one is the default restriction, the other the controlled exception

No questions match "".

All Topics