A Single Input Field Took Down British Airways

In 2018, British Airways disclosed a breach that compromised the personal and financial data of approximately 380,000 customers. The attack vector? A modified script injected into their website's payment page. The UK's Information Commissioner's Office initially proposed a £183 million fine under GDPR. The technique behind it was a form of cross-site scripting — one of the oldest, most persistent, and most underestimated vulnerabilities in web security.

If you've ever wondered what cross-site scripting actually is and why it keeps showing up in breach reports year after year, this is the post that breaks it down. No academic abstractions. I'm going to show you what attackers actually see when they find an XSS vulnerability, why your organization is probably exposed right now, and what you can do about it today.

Cross-Site Scripting Explained in Plain Language

Cross-site scripting (XSS) is a web application vulnerability that lets a threat actor inject malicious code — usually JavaScript — into a page that other users view. When a victim's browser loads that page, it executes the attacker's script as if it were legitimate code from your site. The browser has no way to tell the difference.

That's the core problem. The browser trusts your domain. The attacker exploits that trust.

The injected script can steal session cookies, capture keystrokes, redirect users to phishing pages, or hijack entire accounts. OWASP has listed XSS in its Top 10 web application security risks for over two decades. According to the Cybersecurity and Infrastructure Security Agency (CISA), injection flaws like XSS remain among the most commonly exploited vulnerabilities in public-facing applications.

The Three Types of XSS Attacks

Reflected XSS: The Drive-By Attack

Reflected XSS is the most common type. The attacker crafts a malicious URL containing a script payload and tricks a user into clicking it — usually via a phishing email or social engineering message. The web server reflects the script back in its response, and the victim's browser executes it immediately.

Here's what makes this dangerous: the URL looks like it belongs to your legitimate website. Your employees see a trusted domain and click without hesitation. The script runs once, steals what it needs, and disappears. No trace on the server.

Stored XSS: The Silent Persistence

Stored XSS is worse. The attacker's script gets permanently saved on the target server — in a database, comment field, forum post, or user profile. Every user who views that content triggers the malicious code automatically. No click-bait URL required.

I've seen stored XSS in customer support portals where a threat actor submitted a "support ticket" containing a script. Every agent who opened that ticket had their session token stolen. The attacker then used those credentials to access internal systems.

DOM-Based XSS: The Client-Side Ghost

DOM-based XSS never touches the server. The vulnerability lives entirely in client-side JavaScript that processes user input unsafely. The malicious payload manipulates the page's Document Object Model (DOM) directly in the browser. This makes it invisible to server-side security tools like web application firewalls.

DOM-based attacks are harder to detect and increasingly common in modern single-page applications built with JavaScript frameworks.

What Can an Attacker Actually Do With XSS?

This is where most explanations fall short. They say "an attacker can inject scripts" and move on. Let me be specific about the real-world impact.

  • Credential theft: The script captures login forms or steals session cookies, giving the attacker full account access without knowing the password. Multi-factor authentication won't help if the attacker hijacks an already-authenticated session.
  • Phishing from your own domain: The attacker overlays a fake login form on your legitimate page. Your users see your real URL in the address bar. They enter their credentials willingly. This is social engineering weaponized through code.
  • Ransomware delivery: XSS can redirect users to drive-by download pages that install malware, including ransomware loaders.
  • Keylogging: A persistent script records every keystroke on the page — passwords, credit card numbers, personal messages.
  • Defacement and disinformation: The attacker modifies what users see on your site without changing your actual files. Devastating for trust and brand reputation.

The Verizon Data Breach Investigations Report consistently identifies web application attacks as a top attack pattern, with credential theft as the primary objective. XSS is one of the key enablers.

Why Does XSS Still Exist in 2026?

You'd think after twenty-plus years, we'd have solved this. We haven't. Here's why.

Most XSS vulnerabilities come from a single root cause: the application trusts user input. A developer builds a search box, a comment field, or a URL parameter, and the application renders whatever the user submits without sanitizing it first. That's the entire vulnerability in one sentence.

Modern frameworks like React and Angular provide some built-in XSS protections, but developers routinely bypass them. Using dangerouslySetInnerHTML in React or bypassSecurityTrustHtml in Angular — both named as explicit warnings — is shockingly common in production code.

Add to that the explosion of third-party JavaScript libraries. Your site might load scripts from a dozen external sources. If any one of them gets compromised, every user on your site is exposed. That's exactly what happened in the British Airways attack — a compromised third-party script.

How to Defend Against Cross-Site Scripting

For Developers: Validate, Encode, Escape

  • Input validation: Never trust user input. Validate type, length, format, and range on the server side. Client-side validation is cosmetic, not security.
  • Output encoding: Encode all user-supplied data before rendering it in HTML, JavaScript, CSS, or URL contexts. Use context-specific encoding — HTML encoding won't protect you inside a JavaScript block.
  • Content Security Policy (CSP): Deploy a strict CSP header that prevents inline script execution and restricts which domains can serve scripts. This is your strongest server-side defense against XSS exploitation.
  • Use security-focused libraries: Libraries like DOMPurify sanitize HTML input specifically to prevent XSS. Don't write your own sanitizer.

The National Institute of Standards and Technology (NIST) provides detailed guidance on secure software development practices that address injection vulnerabilities including XSS.

For Security Teams: Test Continuously

Annual penetration tests aren't enough. XSS gets introduced with every code deployment. Integrate dynamic application security testing (DAST) and static analysis into your CI/CD pipeline. Run automated scans on every build. Supplement with manual testing — automated tools miss DOM-based XSS regularly.

For Everyone: Security Awareness Is the Last Line

Here's the reality I keep coming back to in my work: technology alone won't stop XSS exploitation. Reflected XSS requires a user to click a malicious link. That means security awareness training is a direct, measurable defense against XSS attacks.

Your employees need to recognize suspicious URLs, even when they contain your company's domain name. They need to understand why a legitimate-looking page might actually be hostile. I recommend starting with a comprehensive cybersecurity awareness training program that covers social engineering tactics, including how attackers weaponize trusted websites.

Pair that with regular phishing awareness training for your organization that includes phishing simulation exercises. When employees learn to spot crafted URLs in a safe environment, they're far less likely to click real ones.

What Is Cross-Site Scripting? A Quick-Reference Answer

Cross-site scripting (XSS) is a web security vulnerability where an attacker injects malicious scripts into web pages viewed by other users. The victim's browser executes the script because it trusts the page's origin domain. XSS can steal credentials, hijack sessions, deliver malware, and enable phishing — all from within a legitimate website. It is prevented through input validation, output encoding, Content Security Policy headers, and security awareness training.

The $4.88M Reason to Act Now

IBM's 2024 Cost of a Data Breach Report pegged the global average breach cost at $4.88 million. Web application vulnerabilities — XSS chief among them — are a primary entry point. The math is straightforward: fixing XSS in your codebase costs a fraction of that. Training your team to resist the social engineering that delivers reflected XSS payloads costs even less.

Cross-site scripting explained in simple terms isn't an academic exercise. It's a practical briefing for anyone who owns, builds, or defends a website. The vulnerability is old. The exploitation is current. And the defenses are available right now — if you choose to deploy them.

Start with your people. Start with your code. Don't wait for your organization's name to show up in the next breach headline.