Sample: a test of OWASP Juice Shop, a deliberately vulnerable practice site, run locally. Not a customer's site. The findings are that run's own, rewritten in plain words with internal details removed.
Security report · summary
OWASP Juice Shop
Tested 3 September 2026
2
Fix this week
6
Fix this month
7
Worth fixing
In short
The two most serious problems let a stranger take over the administrator account: one by typing database code into the login form, the other by making a fake login token. Either one hands over the whole shop. Several more let any signed-in customer see or change other customers' baskets and addresses, or download the full list of accounts.
Fix first: anyone can make a login token that says they are the administrator; and the login form can be bypassed to sign in as the administrator.
The run filed 16 findings. One is left out here because its written proof described a different issue from its title, one already listed below. Priorities follow each finding's own severity: critical is "Fix this week", high is "Fix this month", medium is "Worth fixing".
The findings
1.Anyone can make a login token that says they are the administrator
Fix this week- How we proved it
- We downloaded the site's public signing key, which it serves to anyone, and used it to sign our own token claiming to be the administrator. Admin-only pages accepted it. A token with a broken signature was refused, so the check is switched on; it can simply be tricked into using the wrong method.
- Why it matters
- A stranger with no account becomes any user, including the administrator. Passwords and two-factor sign-in give no protection.
- How to fix it
- Tell the token check exactly which signing method to accept, and never fall back to another. Replace the signing keys as a precaution and stop serving the key at a public address.
- For the developer
- Every endpoint that accepts a login token · CWE-347 · severity critical, CVSS 9.8
2.The login form can be bypassed to sign in as the administrator
Fix this week- How we proved it
- We typed a short piece of database code into the email box instead of an email address. The site signed us in and handed back a real administrator session.
- Why it matters
- Full control of the shop, its products, orders and users, with no password and no guessing.
- How to fix it
- Pass the email and password to the database as values, never pasted into the query text. Check the email is a real email address before looking it up, and cancel any sessions issued through the broken path.
- For the developer
- POST /rest/user/login · CWE-89 · severity critical, CVSS 9.1
3.Customers can change other customers' delivery addresses
Fix this month- How we proved it
- With two test accounts, the first changed the second's saved address by sending its record number. The change went through, and the reply showed the victim's name, street and phone number.
- Why it matters
- Orders can be sent to an address the attacker chooses, and customers' home addresses and phone numbers can be collected in bulk.
- How to fix it
- Before saving an address, check it belongs to the signed-in customer and refuse otherwise. Never let the request say who owns the record.
- For the developer
- PUT /api/Addresss/:id · CWE-639 · severity high, CVSS 8.1
4.Each login token carries the customer's password in a weak, crackable form
Fix this month- How we proved it
- We signed in, opened our own token (which is only encoded, not encrypted) and found a scrambled copy of our password inside. It matched an old, unsalted scrambling method that is often cracked in seconds.
- Why it matters
- One leaked token can give away the customer's real password, which many people reuse elsewhere.
- How to fix it
- Put only the user's id, email and role in the token. Store passwords with a modern, salted method and upgrade each one at the customer's next login.
- For the developer
- Login token contents · CWE-327 · severity high, CVSS 8.1
5.A password can be changed without knowing the current one
Fix this month- How we proved it
- Signed in as a test account, we set a new password without giving the old one, then signed in with the new password successfully.
- Why it matters
- Anyone who gets hold of a session, for example on a shared computer, can lock the real owner out for good.
- How to fix it
- Ask for and check the current password before any change. Send the new password in the body of the request, not in the web address, so it never lands in logs.
- For the developer
- GET /rest/user/change-password · CWE-620 · severity high, CVSS 7.6
6.The product search reveals every account's email and password
Fix this month- How we proved it
- Without signing in, we added database code to a search. The results came back with an extra row for every account, showing its email and scrambled password, the administrator's included.
- Why it matters
- Every customer's login details can be taken in one request and cracked offline.
- How to fix it
- Pass the search text to the database as a value, never pasted into the query. Stop showing raw database errors to visitors, and move password storage to a modern, salted method.
- For the developer
- GET /rest/products/search · CWE-89 · severity high, CVSS 7.5
7.Confidential files, including a password database, are open to anyone
Fix this month- How we proved it
- Without signing in, we opened a public folder listing and downloaded a password-manager database and a document marked confidential. Both were real files.
- Why it matters
- Staff passwords can be attacked offline, and private business documents are readable by anyone who finds the folder.
- How to fix it
- Take the folder off the public site. If it must stay, put it behind an administrator login, turn off folder listings, and move sensitive files somewhere private.
- For the developer
- /ftp · CWE-538 · severity high, CVSS 7.5
8.Customers can change what is in other customers' baskets
Fix this month- How we proved it
- Signed in as a test customer, we changed the quantity of an item in the administrator's basket by changing one number in the request, then confirmed the administrator's basket now showed the new quantity.
- Why it matters
- An attacker can empty, change or pad other people's orders.
- How to fix it
- Before changing a basket item, check the basket belongs to the signed-in customer and refuse otherwise.
- For the developer
- PUT /api/BasketItems/:id · CWE-639 · severity high, CVSS 7.1
9.Customers can see other customers' baskets
Worth fixing- How we proved it
- Signed in as one customer, we opened four other customers' baskets by changing one number in the address. Each came back in full, with the owner's account number.
- Why it matters
- Anyone with an account can read what every other customer is buying, and any coupons they have applied.
- How to fix it
- Check the basket belongs to the signed-in customer before showing it.
- For the developer
- GET /rest/basket/:id · CWE-639 · severity medium, CVSS 6.5
10.Two-factor sign-in can be guessed without limit
Worth fixing- How we proved it
- We sent 15 wrong six-digit codes in a row with no slowdown or lockout, then the right one, which was accepted. The half-finished login never expired.
- Why it matters
- Someone with a stolen password can keep guessing the second code until they get in.
- How to fix it
- Expire the half-finished login after a few minutes, lock it after about five wrong codes, and slow down repeated attempts from the same account or address.
- For the developer
- POST /rest/2fa/verify · CWE-307 · severity medium, CVSS 5.9
11.An admin settings page is open without signing in
Worth fixing- How we proved it
- One request with no login returned the site's full internal configuration.
- Why it matters
- Gives an attacker a map of the system: internal addresses, features switched on and contact details.
- How to fix it
- Require an administrator login for every admin page by default, and remove internal details from anything that has to stay public.
- For the developer
- GET /rest/admin/application-configuration · CWE-16 · severity medium, CVSS 5.3
12.Browser safety settings are missing or too open
Worth fixing- How we proved it
- We read the response headers on the home page and an uploaded file. The site tells browsers that any other website may read its responses, and three standard browser protections are missing.
- Why it matters
- Makes any future script-injection or token leak easier to exploit and more damaging.
- How to fix it
- Allow only your own sites to read your data, and add a content security policy, a referrer policy and a permissions policy.
- For the developer
- Every response · CWE-942 · severity medium, CVSS 5.3
13.The anti-robot check gives away its own answer
Worth fixing- How we proved it
- We asked for a challenge, read the answer straight out of the reply, and submitted it. Then we submitted the same answer again and it was accepted a second time.
- Why it matters
- Robots can spam the feedback form and hammer the password-reset form, while the check looks like it is working.
- How to fix it
- Never send the answer with the challenge, and let each challenge be used once only, for a short time. Consider a standard anti-robot service instead.
- For the developer
- GET /rest/captcha · CWE-804 · severity medium, CVSS 5.3
14.Anyone can check which email addresses have an account
Worth fixing- How we proved it
- We asked for the security question of a real address and a made-up one. The real one returned a question, the made-up one returned nothing, so the difference gives the game away.
- Why it matters
- Gives attackers a confirmed list of customer emails for phishing and password-guessing.
- How to fix it
- Give the same reply whether or not the account exists, and limit how fast anyone can ask.
- For the developer
- GET /rest/user/security-question · CWE-204 · severity medium, CVSS 5.3
15.Any customer can download the full list of accounts
Worth fixing- How we proved it
- Signed in as an ordinary customer, we requested the account list and received every account's email, role and two-factor status, the administrator's included.
- Why it matters
- Hands over the administrator's identity and every customer's email.
- How to fix it
- Restrict this list to administrators and return only the fields the page actually needs.
- For the developer
- GET /rest/user/authentication-details · CWE-200 · severity medium, CVSS 4.3
Want one for your site?
A real review adds a call to walk you through it and one retest after you fix.
Book a security review