For those who don't know it: The Juice shop is an intentionally vulnerable webshop which 'supports' SQL injection, XSS, DoS and all this kind of nasty stuff. It's nice to run on localhost and play a little around.

So given the facts that it's

  • Well tested
  • Made by security professionals
  • Highly vulnerable

What will be the risks when I publish it to, let's say, Azure?

Something I can imagine is for example nasty JS scripts injected by others, but I know as well that for the DoS case, they make sure the app only freezes for some seconds, instead of until restart, so there are (at least some) safeguards.

  • Risks to what? What are you worried about being impacted?
    – schroeder
    Mar 15, 2019 at 11:24
  • @schroeder Risks to the server or risks to the clients. I don't intend to be more specific, since the possibilities may be way more than what I can think of, and I don't want to exclude that.
    – Br2
    Mar 15, 2019 at 12:23
  • It actually matters, though. Once you include "risks to the clients", then you have a whole other universe of issues to consider.
    – schroeder
    Mar 15, 2019 at 12:32
  • It's exactly because it matters. If hackers could inject scripts that make my computer explode (slightly exaggerated), then I do consider that a risk and that would be something that I want to know on forehand, instead of finding out the hard way.
    – Br2
    Mar 15, 2019 at 13:46

1 Answer 1


If you're running nothing else on the same Azure instance, and nothing on that instance's filesystem contains anything sensitive, then there's not much of a risk factor.

I reviewed a writeup of all the challenges on the Juice Shop, and several of them involve SQL injections that could allow you to modify content on the site. I think your biggest problem is going to be that an attacker could inject a bunch of malicious content and turn your site into a phishing domain or something. Since it's a forum-style product you may also find that spammers fill up your instance with junk. If you're only running this short term and intend to kill the instance after a day or two then I wouldn't worry about it at all.

One countermeasure you could take is to implement HTTP Basic Auth on the webroot of the instance, so that all requests require authentication. That way you can run a public instance but only give access to those who need it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .