One of the most famous examples of a cross-site scripting (XSS) vulnerability is the Myspace Samy Worm created by Samy Kamkar. In October 2005, Kamkar exploited a vulnerability on Myspace that allowed him to store a JavaScript payload on his profile. proving how unsanitized input can execute malicious code in browsers.
XSS happens when websites fail to properly escape characters like quotes or angle brackets, allowing attackers to inject scripts that steal cookies, access user data, or perform actions on behalf of victims. The impact depends on context, browser protections like Same Origin Policy, and whether sensitive data is accessible. XSS can be triggered through HTML tags, attributes, or JavaScript variables, so confirming execution and real risk is key when reporting vulnerabilities.
Types of XSS
XSS (Cross‑Site Scripting) mainly comes in reflected and stored forms. Reflected XSS happens when malicious input is sent in a request and immediately executed without being saved, while stored XSS occurs when the site saves harmful code and later displays it to other users. Subtypes include DOM‑based XSS (manipulating client‑side JavaScript like URL data), blind XSS (executed in areas attackers can't see, such as admin panels), and self‑XSS (affects only the attacker and is usually low severity). The impact depends on where and how the script runs, but most XSS issues can be prevented by properly sanitizing and validating user input before rendering it.
Shopify Wholesale
Difficulty: Low
URL: wholesale.shopify.com/
Date reported: December 21, 2015 Bounty paid: $500
XSS payloads must be crafted based on where the input is rendered, HTML or inside JavaScript. In a 2015 Shopify example, a search box reflected user input inside <script> tags without proper sanitization. HTML tags were encoded, so normal payloads like <script>alert('XSS')</script> failed. But by checking the page source, a hacker realized they could break out of a JavaScript string using input like test';alert('XSS');', which injected and executed malicious code. This shows that even when HTML is sanitized, unsafe handling inside JavaScript can still lead to XSS.
Takeaways
XSS can come from simple unsanitized input fields. When testing, always check the page source to see if your input appears in HTML or JavaScript, since the payload must match its rendering context.
Shopify Currency Formatting
Difficulty: Low
URL: .myshopify.com/admin/settings/general/
Report date: December 9, 2015 Bounty paid: $1,000
XSS payloads don't always run right away, they may execute later when the data is displayed somewhere else. In a Shopify case, attackers injected a malicious payload into a currency settings field that looked harmless at first but later executed in the store's social media sales page when admins viewed it. This shows why inputs must be sanitized everywhere they're rendered, not just where they're submitted.
Takeaways
XSS payloads may not run immediately, so it's important to check all locations where input is used. In this case, submitting the payload on the currency page didn't trigger it, the reporter had to use another site feature to make it execute.
Yahoo! Mail Stored XSS
Difficulty: Medium
URL: Yahoo! Mail
Source: https://klikki.fi/adv/yahoo.html
Date reported: December 26, 2015 Bounty paid: $10,000
Incorrect input sanitization can create new XSS risks. In a Yahoo! Mail case, the editor tried to remove dangerous JavaScript attributes from <img> tags but mishandled malformed HTML and Boolean attributes. This broke the tag structure, allowing an attacker to inject an onmouseover event that executed XSS when users moved their mouse over the page, showing that flawed filtering can introduce vulnerabilities instead of preventing them.
Takeaways
If a site modifies input instead of properly encoding it, test edge cases and developer assumptions (like duplicate or malformed attributes). In this case, testing Boolean attributes with values revealed an XSS vulnerability.
Google Image Search
Difficulty: Medium
URL: images.google.com/
Source: https://mahmoudsec.blogspot.com/2015/09/how-i-found-xss -vulnerability-in-google.html
Date reported: September 12, 2015 Bounty paid: Undisclosed
XSS doesn't always need special characters, sometimes simple payloads like javascript:alert(1) work if user input controls link URLs. In a Google Images case, a researcher modified a URL parameter that became an <a href> value, allowing JavaScript execution in the page's context. Although Google blocked mouse clicks, he bypassed it by using keyboard navigation, showing that alternative interactions can still trigger XSS.
Takeaways
Watch for URL parameters reflected on pages, you control those values, and they can bypass filters, especially when rendered in places like link
hrefattributes where special characters aren't needed. Also, don't assume big companies are bug‑free; even major sites like Google can still have undiscovered vulnerabilities.
Google Tag Manager Stored XSS
Difficulty: Medium
URL: tagmanager.google.com/
Source: https://blog.it-securityguard.com/bugbounty-the-5000-google-xss/
Date reported: October 31, 2014 Bounty paid: $5,000
Best practice is to sanitize input when it's rendered, not just when submitted, because new input methods (like file uploads) might bypass filters. In a Google Tag Manager case, form inputs were sanitized, but JSON file uploads weren't. A researcher uploaded a malicious payload through JSON, and since it wasn't sanitized at render time, it executed XSS, showing why consistent output sanitization is critical.
Takeaways
Key lessons: always test all input methods (forms, uploads, APIs) because they may be processed differently, and don't assume protections are applied everywhere. Also, sanitizing input only on submission is risky, proper security should happen at rendering time. Even big teams make mistakes, so always test despite common defenses.
United Airlines XSS
Difficulty: Hard
URL: checkin.united.com/
Source: http://strukt93.blogspot.jp/2016/07/united-to-xss-united.html
Date reported: July 2016 Bounty paid: Undisclosed
A researcher found XSS on United Airlines by noticing a URL parameter reflected unsanitized in HTML. Even though United tried to block XSS by overriding functions like alert, the attackers analyzed the site's JavaScript, found gaps (like the unprotected writeln function), and used payload tricks with URL fragments and iframes to bypass filters. The lesson: study client‑side defenses closely, custom protections often have weaknesses that can be bypassed with creative testing.
Takeaways
Key takeaways: stay persistent and analyze why payloads fail instead of giving up; blacklists of JavaScript functions often signal weak defenses and potential XSS gaps; and solid JavaScript knowledge is crucial for understanding and exploiting more complex vulnerabilities.
Summary
XSS is common and often easy to miss. Test inputs with payloads, but also examine how sites sanitize data, especially when they modify input or sanitize only on submission. Try all input methods, watch for reflected URL parameters, and consider whether input appears in HTML or JavaScript. Also remember that XSS may execute later in different parts of the site, not immediately.
See you in next chapter!