XSS (Cross-Site Scripting)

What is XSS (Cross-Site Scripting)?

Cross-site scripting is a web vulnerability where an attacker injects malicious code into a page that other people then load in their browser. The browser trusts the page, so it runs the script as if the site wrote it. From there an attacker can steal session cookies, read what a user types, or act as that user. XSS targets the people visiting a site, which is what separates it from a server-side attack.

There are three common forms. Stored XSS lives in the database, planted through something like a comment field, and fires for every visitor who loads it. Reflected XSS bounces off the server through a crafted link, often in a search result that echoes input straight back. DOM-based XSS happens entirely in the browser when client-side code handles untrusted data unsafely. A classic example is a comment box that saves tags and replays them to every reader. The root cause is almost always the same. Untrusted input ends up in the page without being escaped or sanitised.</p> <p>The defences are well understood. Escape output based on where it lands, validate input on the way in, and apply a Content Security Policy that blocks scripts from running where they should not. Modern frameworks escape by default, which helps, but any place that injects raw HTML can reopen the door.</p> </section> <section id="dallonses"> <h2>XSS (Cross-Site Scripting) at Dallonses</h2> <p>We treat every value that comes from a user as hostile until proven otherwise. Output gets escaped by default, raw HTML injection is reviewed line by line, and Content Security Policy headers ship as part of the build rather than as an afterthought. The frameworks we work in escape automatically, and we are careful about the few escape hatches that bypass that protection.</p> <p>This is part of how we approach QA strategy and governance across web development and custom web applications. Security checks sit inside the review process, not in a separate phase that gets cut when timelines tighten. We have built public-facing products for brands where a single injected script would reach a large audience fast, and that reality keeps the discipline tight from the first commit.</p> </section> <section id="cta"> <p>Building something public that handles user input? Let's make sure it can't be turned against your visitors.</p> <button>Talk to us about secure builds</button> </section>