Security

Cross-site scripting is one of those vulnerabilities that never really goes away. We get better frameworks, safer templating, stricter defaults, and still XSS shows up in bug bounty reports every day. The reason is simple: if an attacker can get the browser to execute JavaScript you didn’t intend to run, they can often act as the user, steal data, or pivot deeper into your app. Content Security Policy, or CSP, is one of the few browser features that can meaningfully reduce the blast radius of XSS. It is not a silver bullet. It will not magically fix unsafe HTML rendering. But a good CSP can turn “one bad escaping bug equals account takeover” into “the payload just doesn’t run.” ...

Cross-site scripting prevention gets a lot harder than it should because people hear “sanitize input” and stop there. That’s not enough. If you remember one thing from this tutorial, make it this: XSS is prevented at output time, based on the exact context where data is rendered. Output encoding is the boring, reliable workhorse of XSS defense. It’s not flashy, but it’s the thing that stops untrusted data from turning into executable HTML, JavaScript, or CSS in the browser. ...

Cross-site scripting is one of those vulnerabilities that keeps showing up because it’s fundamentally simple: untrusted data ends up in a place where the browser treats it as code. But “XSS” isn’t just one thing. In practice, you’ll usually hear about three flavors: Reflected XSS Stored XSS DOM-based XSS They all end with attacker-controlled JavaScript running in a victim’s browser, but the way the payload gets there matters a lot for both exploitation and prevention. ...

Cross-site scripting, usually shortened to XSS, is one of those web security bugs that sounds old-school but still shows up everywhere. If you build web apps that display user-controlled content, you need to understand it. Not just the definition, but how it actually happens in real code. The short version: XSS happens when an attacker gets your site to treat untrusted input as executable code in the browser. Usually that means JavaScript, but the real issue is broader than “someone injected a script tag.” The browser is parsing HTML, attributes, URLs, CSS, and script contexts differently, and if you put user data into the wrong place without the right protection, the attacker can make the page do things you never intended. ...

Cross-site scripting in React and Next.js is one of those topics that sounds simpler than it really is. A lot of developers hear “React escapes output by default” and mentally file XSS away as mostly solved. That’s true right up until you touch dangerouslySetInnerHTML, render CMS content, build a markdown feature, pass untrusted values into URLs, or mix server and client rendering in ways that make assumptions drift. The good news: React and Next.js give you a strong baseline. The bad news: they do not make you XSS-proof automatically. ...