Finding and proving application security vulnerabilities requires a lot of skill. However, many of them are easy to exploit. If you want to write better code, you should know how others may prey on your mistakes. We compiled a Top-10 list of web applications that were intentionally made vulnerable to Cross-site Scripting (XSS). They were created so that you can learn in practice how attackers exploit Cross-site Scripting vulnerabilities by testing your own malicious code.
The sites in this Top-10 list are practical hacking challenges or collections of such challenges. Some of them are simple and help you learn the basics of Cross-site Scripting. Others present more difficult security flaw challenges for seasoned engineers. You may use this list to practice and test your skills but you may also use it to educate others about how important it is to effectively protect code.
--disable-xss-auditor
.#1: Google XSS Game
In 2014, Google created a game that shows you how easy it is to exploit XSS vulnerabilities. It was launched to spread security awareness and to promote the bug bounty program. The game has 6 levels of increasing difficulty.The Google XSS game is simple. All it requires is basic JavaScript knowledge and a bit of Python awareness. The author of this article who is not a security engineer made it all the way to level 6 without googling for solutions. This means that certainly, you can do it, too.
#2: alert(1) to win
This set of challenges was created by Erling Ellingsen in 2013. Similar to the Google XSS game, it is a series of 8 increasingly difficult levels that explore different aspects of Cross-site Scripting. In general, the challenges are more difficult and require a bit more coding experience.The greatest aspect of this game is the fact that you can immediately see the results of the code that you enter and the console output. It also has a competitive aspect. When you solve a level, you can see a list of other winners and their scores. The score is based on how long the payload is. The fewer characters in your XSS, the better your position.
#3: prompt(1) to win
The security researcher from Hong Kong known as filedescriptor created this site in 2014, inspired by alert(1) to win. It contains 20 challenges (4 of them hidden) and is more difficult than the two games described above.Similar to alert(1) to win, this game also shows you the results of your actions as you type: the HTML code and the visual output. However, it does not show the console so you have to monitor errors for yourself. Note that the last levels of this challenge may prove to be impossible to beat today due to changes in browser engines.
#4: XSS Challenges by yamagata21
The set of Yamagata’s XSS challenges is one of the oldest XSS games. It goes back all the way to 2008 and it contains 19 stages starting from the most basic XSS exercise.Unlike the above challenges, this one provides no live results, no live HTML output, and no server-side source code, so you have to do all the work yourself. The page is constructed just like a real web page that is vulnerable to XSS. This also means that you need to make sure that XSS protection in your browser is turned off. Also, note that some of the stages (for example, 17 and 18) are no longer applicable and you cannot complete them because they require an old version of Internet Explorer to work.
#5: XSS Challenges by nopernik
This set of challenges was created by Alexander Korznikov (nopernik) in 2016 so it is relatively young. Similar to yamagata’s game, it has 19 challenges at the moment but new ones are added with time so you can hopefully expect some more in the future.Similar to yamagata’s game, this is also just a simple HTML page with basic JavaScript code and no extra help. In this case, it is also very important to turn off client-side XSS filters. Higher levels are not hidden, so you don’t have to progress to have access to them. However, it may prove to be more difficult because there seem to be no solutions to be found online.
#6: XSS Polyglot Challenge
The Polyglot Challenge, designed by filedescriptor from Hong Kong (the author of prompt(1) to win) is not for beginners. It requires you to come up with a payload that works in most contexts. The more contexts you can cover and the shorter the payload, the higher your ranking.Initially, this was a black-box challenge: the author did not disclose the contexts in which he tested the payload. Now, he lists the contexts on the page, so the challenge is easier. To be most effective, it’s best that you create these contexts on a local web server and test your payload there before submitting it.
#7: Vulnweb by Acunetix
This list would not be complete if it did not contain our own library of intentionally vulnerable sites. Vulnweb is not just about XSS. It contains several applications with different technologies such as PHP and ASP. Most of them are susceptible to some form of XSS but also to SQL Injection and much more.The site was originally launched to help you test automated vulnerability scanners. Therefore, it is not designed as a set of challenges. Your challenge is to try to find the vulnerabilities yourself. After that, you can use Acunetix to see how many you missed.
#8: OWASP WebGoat Project
The WebGoat project is not an online site. It is an open-source application that you need to download and run yourself. It helps you learn through challenges that cover not only XSS (including DOM-based XSS, which is less common) but many other vulnerability types.WebGoat is currently at version 8.0 and it is available as either a standalone download (a JAR file) or as a Docker image. In addition to WebGoat, there are several other similar OWASP projects, for example, the Juice Shop.
#9: Hack.me XSS Library
The Hackme community project is a library of third-party code. Anyone can upload code examples for others to practice. When you want to test your skills, Hackme generates a single-user instance that you can work with.The Hackme library is categorized by types of vulnerabilities. The link provided above leads to just the XSS part of the library. It includes a lot of different examples, both simple and complex ones. You can practice different types of XSS including stored XSS, reflected XSS, and DOM-based XSS.
#10: cure53 XSS Challenge Wiki
If our list is not enough for you, you can always follow up with the XSS challenge wiki prepared by cure53 and hosted on GitHub. Despite not being updated for a while, it still contains a notable list of different challenges from the past.Most of the challenges described on this wiki are provided together with solutions. However, some of the third-party vulnerable websites are unfortunately no longer working.
Frequently asked questions
Cross-site scripting (XSS) is a type of vulnerability where the code sent by the attacker is executed back in the user’s browser. The malicious code is written in a scripting language, usually JavaScript.
There are three primary types of cross-site scripting vulnerabilities. Stored (persistent) XSS happens when an attacker injects malicious code into the target application – when victims visit the page, their browsers execute this code. Reflected (non-persistent) XSS happens when an attacker uses a malicious phishing link and malicious code is executed as part of the response from the server. DOM XSS happens within the Document Object Model (DOM) of the browser, often with no information sent to the server.
It is completely legal to practice cross-site scripting on sites that are dedicated for that purpose. In this article, you can learn about the most popular sites that are intentionally vulnerable. You can also install your own local vulnerable applications such as bWAPP, OWASP Juice Shop, or DVWA and use them to practice.
The best way for someone with programming or administration knowledge to become a white-hat hacker at the moment is to learn on your own by reading a lot on the web and practicing. You will find a lot of educational articles on the Acunetix site and the Acunetix blog.
Learn why white-hat hackers are very important to IT security.
Get the latest content on web security
in your inbox each week.