The solution to Secure Code Review Challenge #4: File Converter is live!
This one’s a reminder that authentication is not authorization. The app does a lot right: bcrypt password hashing, express-mongo-sanitize against NoSQL injection, execFile (not exec) so command injection is a dead end, --sandbox mode against a real Pandoc SSRF CVE, EJS auto-escaping + CSP against XSS, textContent instead of innerHTML on the client. Every classic injection sink is genuinely closed.
But the per-job routes only check who you are — never whether it’s your job. They fetch by job ID alone, with no comparison to the caller’s user ID. And job IDs aren’t random: they’re just today’s date plus a per-day counter starting at 1.
Any registered account can guess a job ID and download a stranger’s uploaded document. Proved it live with two accounts — one stealing the other’s “confidential” file.
Watch the full walkthrough: https://youtu.be/R_xdc6y9Rho
Read the write-up: the-secure-code-review-challenge/solutions/004-file-converter/SOLUTION.md at main · mohamed-osama-aboelkheir/the-secure-code-review-challenge · GitHub
Try Challenge #4 yourself first: the-secure-code-review-challenge/challenges/004-file-converter at main · mohamed-osama-aboelkheir/the-secure-code-review-challenge · GitHub
Two things before you dive in:
Challenge #5 is already live in the repo: [link]
Watch → Custom → Releases on the repo to get notified the moment new challenges/solutions drop, instead of checking back manually: Releases · mohamed-osama-aboelkheir/the-secure-code-review-challenge · GitHub
If you work through it, I’d love to know: when you hit a route that takes an object ID from the URL, is “checking ownership” a reflex for you, or does seeing requireAuth on the route make it feel already covered?