New level proposal: Server-Side Request Forgery (SSRF) in JavaScript/Node.js — Season 2

[ggeorgeazevedo]

👋 Hi! I'd like to contribute a new level for the Secure Coding track. I picked one of the combinations explicitly listed as a priority in CONTRIBUTING.md, and I checked the existing proposals in this category first — SSRF has not been proposed before.

Vulnerability

Server-Side Request Forgery (CWE-918), with the twist that the code already has a "security check" that looks reasonable but is trivially bypassable. Three bypasses are covered:

1. Alternative loopback representations (the blocklist matches the string localhost / 127.0.0.1, not the resolved address).
2. Link-local address 169.254.169.254 to reach a cloud instance metadata service.
3. An allowed external URL that replies with a 302 redirect to an internal host — the check runs on the URL the user submitted, never on the final destination.

This makes the level about validating the resolved destination rather than filtering strings, which is the actual lesson behind SSRF.

Programming Language

javascript (Node.js + Express), matching the stack and test tooling already used in Season-2/Level-3 and Season-2/Level-5 (mocha + chai + supertest). Happy to ship it as TypeScript instead if you prefer.

Scenario

"Mission Control" — a space agency runs an internal dashboard where operators preview live telemetry feeds published by partner observatories. To keep it flexible, the dashboard lets an operator paste any feed URL, and POST /telemetry/preview fetches it server-side and renders the response body back to the operator.

The dashboard runs on the same host as an internal admin API and inside a cloud VM with an instance metadata endpoint. The developer, aware that "fetching user URLs is dangerous", added a check that rejects URLs containing localhost or 127.0.0.1 and called it a day. An attacker with nothing but the public form can reach both internal services.

The player's job: keep legitimate external previews working (tests.js must stay green) while making the internal accesses fail (hack.js must turn green).

Proposed file layout

Following the existing conventions, as Season-2/Level-6/:

code.js          # vulnerable Express app with the naive blocklist
hack.js          # the three SSRF exploits (fails on code.js, passes once fixed)
tests.js         # legitimate functionality that must keep passing
solution.js      # one working fix: resolve DNS, block private/link-local ranges, no redirects
hint-1.txt       # nudge towards "the check runs on a string, not on a destination"
hint-2.txt       # nudge towards redirects and DNS resolution
package.json

Plus the matching section in Season-2/README.md (storyline, languages, what's in the repo, time to start), consistent with the other levels.

One design note: the tests spin up the "internal" victim services locally on ephemeral ports and stub the metadata endpoint, so no outbound network access is required — the level stays deterministic and works offline inside Codespaces.

Next steps

I already have a working draft of the level (vulnerable code, exploits, solution and tests all behaving as described). I'll open the PR as soon as this proposal gets a green light. Happy to adjust the scenario, the language, the difficulty, or the number of bypasses if you'd rather keep it tighter.

Thanks for maintaining this game — it's a great resource. 🎮 🔐

[jkcso]

Thanks! Please coordinate with @xcorail here.
My advice is to either have an additional level in season 2, but placed carefully based on difficulty OR have a dedicated folder for extra levels such as this one and the other open PR we have for those who want to play extra, in a way that looks and feels like reading an appendix.

[xcorail]

Thanks @ggeorgeazevedo for this proposal!

I will ask around if there are other 2-3 challenge ideas, so we could make another full season with the 2 we already have.
If not, of if it would take too long, we could indeed publish it as a "bonus short season".

So please open the PR as a new Season rather than a new challenge of Season 2.

[ggeorgeazevedo]

Thanks a lot @jkcso and @xcorail for the quick and clear feedback! 🙏

Going with @xcorail's direction, I've opened it as a new season instead of a Season 2 level: #216

A few notes so it's easy to fit into whatever you decide:

• I used Season-5/ simply because it's the next number, but I noticed CONTRIBUTING.md earmarks Season 5 for the ProdBot/AI track. Renaming the folder is trivial, so if you'd rather call it a bonus season, or reserve 5 for AI, just tell me and I'll push the rename.
• The season README.md is written as a home for community-contributed levels, with this one as Level-1. That way Adding New Level: Lua Metatable hooks #128 (Lua metatable hooks) can drop in as Level-2 without restructuring anything, which I think matches @jkcso's "appendix" idea while still being a Season.
• The level needs no outbound network access — both tests.js and hack.js spin the partner feed and the internal services up on ephemeral loopback ports, so it stays deterministic inside Codespaces.

@xcorail on gathering 2–3 more challenges: I'd be happy to write a second one myself. Broken Access Control (IDOR) in TypeScript would be my suggestion, since it's on the priority list in CONTRIBUTING.md and isn't covered anywhere in the game yet. Say the word and I'll open a separate proposal for it so you can review the scenario before I build it.

Happy to adjust anything in the PR — naming, difficulty, or the framing of the season.

[xcorail]

Thanks @ggeorgeazevedo

I'd be happy to write a second one myself.
Of course, you can go ahead!

Note: Apologies in advance if review and responses take time, we are understaffed atm, but know that we appreciate and value your contributions!

[ggeorgeazevedo]

Thanks @xcorail! Took you up on it — the second level is in, pushed to the same branch as #216 so the season lands as one reviewable unit instead of two PRs waiting on each other.

Season 5 - Level 2: Paperwork — Broken Access Control in TypeScript. An expense reimbursement API where the authentication is solid and the authorization is missing: a read endpoint that checks the session but not the ownership, an update endpoint that merges the request body straight into the record, and an approval endpoint that takes the caller's role from a request header. Three exploits, unit tests, one solution and two hints, all in-memory so it runs offline.

Details and verification steps are in the PR. No rush on review at all — take the time you need, and thanks again for the quick steer on the season structure.