OWASP Juice Shop: what we'd send the owner.
We ran our $49 check on OWASP Juice Shop, a working e-commerce app built for security training. It has genuine holes, so we can show you a finished report with nothing redacted. Yours would look exactly like this, just with your site, your URLs, and your own findings.
If you owned this site, here's the email I'd send you.
Your site has working holes. Customer info is sitting out in the open, your API hands records to anyone who asks, and an attacker can drop scripts onto your pages. Every finding below came from a scan I can re-run on demand.
List every file on the server, pull user records straight from the API, plant malicious code on your product pages, or hijack a logged-in session. The wide-open CORS setting makes most of this a one-line attack.
Require login on every API endpoint that returns user data. Remove the public /ftp directory. Change CORS from "*" to your own domain. Add Content-Security-Policy, HSTS, and Referrer-Policy headers.
Critical findings
Fix these first. Any one of them could leak customer data or hand over an account.
Exposed FTP directory listing
Hitting /ftp returns a full file listing with no login. Anyone on the internet can browse it and download whatever's there.
Unauthenticated API: user data exposed
The /api/Users endpoint hands back user records without asking for a login. It does check for a header, but the error response leaks enough structure to map the API. Meanwhile /api/Products returns full product data including internal timestamps and deletedAt fields to anyone who asks.
createdAt, updatedAt, and deletedAt from public API responses.Wildcard CORS header: Access-Control-Allow-Origin: *
Every response carries a wildcard CORS header, which means any site on the internet can call your API from a user's browser and read the response. An attacker with a malicious page can lift data out of your app one-step.
* for your actual domain(s). Example: Access-Control-Allow-Origin: https://yourdomain.comHigh-severity findings
Fix these soon. They don't break the site on their own, but they make every other attack easier.
No Content-Security-Policy header
There's no CSP set. If a script ever slips in through a customer review, a product description, or a compromised dependency, the browser has nothing telling it to refuse.
default-src 'self'; script-src 'self'; style-src 'self' fonts.googleapis.comNo HTTP Strict-Transport-Security (HSTS)
HSTS isn't set. A first-time visitor on a hostile network (coffee shop wifi, hotel, airport) can get quietly downgraded from HTTPS to HTTP before they ever reach you.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadMedium-severity findings
Not on fire, but worth tidying up before you ship anything new.
A few security headers are missing
Referrer-Policy, Permissions-Policy, and X-Content-Type-Options aren't set. Small headers, easy wins. They add another layer if something else slips through.
Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy: camera=(), microphone=(), and X-Content-Type-Options: nosniffX-Recruiting header leaks an internal URL
The response includes X-Recruiting: /#/jobs, which quietly exposes an internal path. It's free information for anyone poking around.
robots.txt is acting as a treasure map
robots.txt blocks /ftp, which has the opposite of the intended effect: it tells every attacker exactly where to look. Sensitive paths shouldn't be mentioned there at all.
SSL/TLS check
Some good news. Encryption is the one area already pulling its weight.
Want one of these for your site?
This came from an actual scan, not a template. Yours would have the same format with your URLs, your findings, and your fixes.