Run the scanner against a deliberately vulnerable application in an isolated lab, write down the flaws you expect it to find, and score what it reports. Treat the result as a check of basic coverage, not as a ranking of tools, because lab apps differ from yours.
Why use a vulnerable app
You cannot judge a scanner by its marketing, and you cannot test it on a real system without risk. OWASP maintains two training applications built to be attacked. OWASP describes Juice Shop as an insecure web application for training, awareness demos and capture-the-flag events, and says security tools can use it as a guinea pig to see how well they cope with JavaScript-heavy frontends and REST APIs. OWASP describes WebGoat as a deliberately insecure application for learning flaws common in Java applications, and notes that security professionals often need to test tools against a platform known to be vulnerable to check they perform as advertised.
Lab safety first
WebGoat's own project page warns that while it runs your machine can be extremely vulnerable to attack, and that its default configuration binds to localhost. Follow that advice.
- Run both apps on a machine or container with no sensitive data.
- Keep the lab off the corporate network, or bind to localhost.
- Never expose either app to the internet.
- Delete the lab when finished.
Steps
- Pick one app per question. Juice Shop for single-page app and API handling, WebGoat for server-rendered Java flows.
- Write the expected list first. Before you scan, note five to ten flaws you know exist, such as injection in a search box or weak access control. Use each project's documentation for the list.
- Scan with your normal policy. Do not tune it for the lab, or the test says nothing about real use.
- Record the time and request count.
- Score the report. For each expected flaw, mark found, found late or missed. Count extra findings and check a sample by hand.
- Repeat after a change. Re-run when you update the scanner or policy, as a regression check.
A scoring sheet
| Expected flaw | Found? | Time to find | Notes |
|---|---|---|---|
| Injection in search | Yes or no | Minutes | Evidence quality |
| Broken access control | Yes or no | Minutes | Needed two accounts? |
| Client-side route not crawled | Yes or no | Minutes | Needed a browser crawl? |
What the test cannot show
- Your app is different. Your login, your frameworks and your business rules are not in the lab.
- Lab apps are noisy by design. Almost everything is vulnerable, so the false positive rate here tells you little.
- Business logic flaws need knowledge of your rules and will not appear in a generic exercise.
- It is a snapshot. Versions change, and the apps change with them.
Use the lab to catch obvious gaps, such as a scanner that cannot crawl a single-page app at all. Then run a trial on a copy of your own staging environment.
A worked example
A team wants to know whether a scanner can handle their JavaScript-heavy front end before they point it at their own staging site. They set up a lab.
- They start Juice Shop in a container on a lab machine, bound to localhost, with no sensitive data present.
- They write an expected list of eight flaw types from the project's own challenge list, such as injection in a search field, broken access control on basket items, and exposure of a hidden page.
- They run the scanner with its usual policy, using a browser-driven crawl.
- They record the result for each expected flaw.
| Expected flaw | Result | Notes |
|---|---|---|
| Injection in a search field | Found | Strong evidence |
| Reflected input in a client-side route | Missed | Route never crawled |
| Access to another user's basket | Missed | Needs two accounts |
| Hidden page exposure | Found late | After a longer crawl |
| Verbose error messages | Found | Passive check |
| Weak session settings | Found | Passive check |
| Open redirect | Found | Needs the right payload |
| File upload checks | Missed | Form handling gap |
These results are an illustration of how to record the outcome, not measurements of any tool. Two lessons come out of such a table. First, a browser-driven crawl and a second user account change results sharply. Second, the misses point to configuration work, not just to a weak tool. The team adds a second account and a longer crawl and reruns.
Running more than one lab
Juice Shop is a single-page app with a REST API, and WebGoat is a Java application with server-rendered lessons. Each tests a different capability. A scanner that does well on one may struggle on the other, which tells you something about the kinds of apps it handles. Choose the lab that resembles your own stack most closely.
Turning the lab into a regression test
Keep the scorecard. Whenever you upgrade the scanner or change a policy, run the lab again and compare. A drop in found flaws signals a regression, and an increase shows a gain. Store the scorecard in version control.
Limits to remember
| Limit | Consequence |
|---|---|
| Labs are built to be broken | Almost everything is vulnerable, so false positive counts mislead |
| Your app has custom logic | Business rules are not in the lab |
| The labs change between versions | Record the version you tested |
| One run is one data point | Repeat and compare |
Use the lab for people too
The same lab is a safe place to train your developers to read scan reports. Walk through a finding together, reproduce it by hand, and discuss the fix. A team that has seen a real injection in a safe place treats scanner output more seriously.
Where Safeguard fits
A lab scan checks a web tester. To check the open source packages in your own code, Safeguard offers SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare what a scan reports with the expected-flaw list you would write first.
Quick check
Can I rank tools by their Juice Shop score?
No. It checks basic coverage only, and your own app behaves differently.
Is it safe to run these apps on a laptop?
Only in isolation and bound to localhost, with no sensitive data on the machine.
Which lab should I start with?
Pick the one closest to your stack: Juice Shop for single-page apps with REST APIs, WebGoat for Java server-rendered applications.
Sources
Last reviewed: 19 October 2026.
