What is a deliberately vulnerable web app?

A deliberately vulnerable web app is an application built with known security flaws so that people can practise finding and fixing them legally. OWASP Juice Shop, DVWA and WebGoat are well-known examples. You run one yourself or use a hosted instance whose owner explicitly permits attacks, such as CyberGym.

Why it matters

Learning to test web apps needs a target, and testing a real site without permission is unauthorised access in most jurisdictions, whatever the intent. A deliberately vulnerable app removes that problem: the owner's permission is the whole point of the app, and the flaws are there to be found.

They also teach better than reading. OWASP keeps a directory of vulnerable web applications for this reason, and the best of them cover the OWASP Top 10 with challenges that track your progress. OWASP Juice Shop, for example, ships a scoreboard of challenges sorted by difficulty and category, and a free companion book, Pwning OWASP Juice Shop, that explains each one.

Example: CyberGym, a hosted Juice Shop you may attack

CyberGym at cybergym.hackergpt.app is a hosted OWASP Juice Shop. Its owner grants full permission to attack the applications in scope, so you can start without installing anything. A first look shows the version and a hint the app leaves on purpose:

$ curl -s https://cybergym.hackergpt.app/rest/admin/application-version
{"version":"19.1.1"}
$ curl -sI https://cybergym.hackergpt.app/ | grep -i x-recruiting
X-Recruiting: /#/jobs

From there, open the shop in a browser, find the score board (finding it is itself a challenge), and pick a category you want to learn: broken access control, injection, XSS. Because the app is built to be attacked, you can go further than you ever should on a real site and see what each bug class actually allows.

If you prefer to run one locally, Juice Shop starts from a single Docker image. Either way, the habits are the ones you will need on your own app: note each request, keep the evidence, and write down how you would fix what you found.

Common mistakes

  • Assuming any public demo is fair game. Only attack a hosted instance whose owner says in writing that you may. A vendor's demo site is not a practice target.
  • Exposing a local vulnerable app to the internet. Run it on localhost or an isolated network. It is vulnerable on purpose, to anyone who can reach it.
  • Only collecting solved challenges. For each one, write down the fix. That is the part you will use on your own code.
  • Staying on practice targets forever. Move on to testing your own site, where the bugs are not labelled.

Related terms

Go deeper

Sources

Test only sites you own or have written permission to test. To practise without one, use CyberGym, a legal, deliberately vulnerable target. Practise on CyberGym.