Easy

WebVerse - Role RipTide

WebVerse - Role RipTide

Lab: Role RipTide
Difficulty: Easy
Theme: AuthZ / IDOR-ish feel, but the real bug is mass assignment (role field)
Goal: Obtain Flag Value
Entry: http://localhost:8092 (WebVerse default)

TL;DR

  1. Create an account and log in.
  2. Visit Settings and notice profile updates are sent via JSON.
  3. Intercept the request and modify "role": "admin" (mass assignment).
  4. Re-login (or refresh token/session as needed) and see dashboard accessing the admin route/API.
  5. Fuzz the admin API for endpoints
  6. Pull the flag from /api/v1/admin/config.

Recon

Opening the site shows a simple portal-style web app: register/login, then a dashboard with “records” (engagements / projects).

The story hints at “briefly saw a client record they shouldn’t have access to” — that’s classic authorization trouble. So the plan is:

  • Map endpoints
  • Find anything role-based (admin vs user)
  • Look for write paths that allow role changes

Enumeration

After registering and logging in, there are a couple areas worth clicking:

  • Dashboard (records list)
  • Settings (profile updates)
  • Anything “classified” / “admin” / “internal”

Key things to watch for:

  • Auth token location (cookie vs Authorization header)
  • Role stored in JWT vs fetched from DB
  • Any JSON update endpoints (PATCH /me, PUT /profile, etc.)

Register + Login

Create a normal user and log in.

You should see a dashboard, and (importantly) a Settings page where you can change account fields.

That’s often where “role” bugs hide:

  • Developers want to let users change name, email, etc.
  • They accidentally accept extra fields like role, is_admin, permissions, plan, etc.

Settings: Finding the Bug

On the Settings page, change something harmless (like your display name) with your proxy intercepting.

You’ll see a request like:

  • POST /api/v1/account/update
  • JSON body with profile data

In the Role RipTide source, the update handler takes user-provided JSON and applies it too broadly.

What the Settings page tries to do

The UI tries to enforce a normal user role by including something like:

  • "role": "user"

…but the server shouldn’t trust the client with role assignment at all.

The actual vulnerability: Mass Assignment

Instead of whitelisting allowed fields (name, maybe avatar, etc.), the server accepts a JSON blob and updates account fields too freely — including role.

That means we can just change our role.

Exploitation: Flip Role to Admin

Intercept the profile update request and modify the JSON body.

If you see:

{
  "email": "[email protected]",
  "name": "Leighlin Ramsay",
  "password": "",
  "phone": "",
  "role": "user"
}

Change it to:

{
  "email": "[email protected]",
  "name": "Leighlin Ramsay",
  "password": "",
  "phone": "",
  "role": "admin"
}

Forward the request.

Confirming the change

There are two common behaviors after role escalation:

  1. Immediate: the next page refresh shows admin-only links/content
  2. On re-auth: your token was issued before the role change, so you must log out/in (or wait for the app to re-check role server-side)

In this lab, Ghost-style “migration lock” pain aside, the web app behavior is typically:

  • Role is read from the DB on protected routes (good for us)
  • Or role is embedded in a token (then you need to re-login)

So if you don’t immediately see admin features:

  • log out and log back in
  • refresh the dashboard
  • try a direct browse to likely admin endpoints
curl 'http://localhost:8092/api/v1/account' -X PUT -H 'Content-Type: application/json' -d '{"name":"Leighlin Ramsay","email":"[email protected]","phone":"","password":"","role":"admin"}' -H 'Cookie: apv_token={JWT_TOKEN}'

Privilege Escalation: Admin-Only Routes

Once you’re “admin”, the lab gates the sensitive content behind an admin check.

The Classified Page

There’s a classified dashboard route:

  • /dashboard/classified

If your role is still user, it should redirect or deny you. As admin, it loads.

This page is basically a narrative proof: “you now see what you shouldn’t.”

The Real Prize: Following the Admin API Trail

Once we’ve got access to the Classified Projects page, the page itself becomes the giveaway.

Pop open your browser dev tools (F12) and head to the Network tab. Refresh the page and watch what it loads. Among the usual static assets, you’ll spot the important part: the frontend is making calls to an admin API endpoint to fetch the classified data.

That’s the “oh?” moment — this page isn’t just rendering server-side. It’s acting like a thin client for an internal-ish admin API route. If it’s calling one admin endpoint, there’s a good chance there are more sitting under the same path.

Fuzzing the Admin API for More Endpoints

With the base route identified from the Network tab, the next step is simple: enumerate what else exists under that admin API prefix.

I’ll use ffuf with a SecLists discovery wordlist to brute-force common endpoint names:

ffuf -u 'http://localhost:8092/api/v1/admin/FUZZ' -mc all -w ~/tools/wordlists/SecLists/Discovery/Web-Content/raft-medium-directories-lowercase.txt --fc 404 -H 'Cookie: apv_token={JWT_TOKEN}'

Before long, something interesting pops:

  • config

Which gives us a new endpoint:

  • GET /api/v1/admin/config

Getting the Flag

Now it’s just a request away:

curl 'http://localhost:8092/api/v1/admin/config' -s -H 'Cookie: apv_token={JWT_TOKEN}' | jq .

The response is a JSON configuration blob — and inside it is the flag.

That’s the full chain in one line:

role escalation → Classified Projects access → Network tab reveals admin API → fuzz /api/v1/admin/* → find /config → flag.

Wrap-Up: What Role RipTide Teaches About Mass Assignment and API Authorization

Role RipTide looks like an IDOR/AuthZ-style lab at first (and the story intentionally nudges you in that direction), but the real bug is more specific — and extremely common in modern web apps:

mass assignment on an account update endpoint.

The vulnerable pattern is simple:

  • the frontend sends a JSON profile update request
  • the backend accepts too many client-controlled fields
  • a sensitive field (role) is not server-side protected
  • a normal user can set their own role to admin

That turns a routine profile update into a privilege escalation.

Why this matters in real applications

This is the kind of bug that happens when developers:

  • trust client-supplied JSON too much
  • reuse generic model update logic
  • fail to whitelist safe fields
  • assume “the UI won’t let users change that field” is enough

In practice, mass assignment bugs can affect fields like:

  • role
  • is_admin
  • permissions
  • account_type
  • billing_plan
  • organization_id
  • email_verified

Role RipTide is a clean example of how a single property-level authorization failure can collapse the rest of the app’s security model.

What the exploit chain teaches

This lab also teaches a good attacker workflow:

  • do basic recon first (map pages, flows, roles, endpoints)
  • watch profile/settings requests carefully
  • test client-controlled JSON fields for sensitive properties
  • re-auth if needed after privilege changes
  • use the browser Network tab to discover admin API routes
  • fuzz the admin API for additional endpoints (/api/v1/admin/*)
  • retrieve sensitive config data once access controls fail

Security lesson (how to prevent this bug)

The fix is not “hide the role field in the UI.” The fix is:

  • server-side allowlisting of profile fields
  • never accepting privileged fields from untrusted clients
  • enforcing authorization checks at every sensitive route
  • separating “user profile updates” from “admin account management”
  • logging and alerting on role/permission changes

Final takeaway

Role RipTide is an easy lab, but it teaches a very real web/API security failure mode: mass assignment leading to privilege escalation, followed by admin API enumeration and sensitive configuration exposure.

If you want to practice this lab and others like it, you can run WebVerse labs locally and explore more writeups at webverselabs.com.

FAQ: Role RipTide (WebVerse) — Mass Assignment, Privilege Escalation, and Admin API Enumeration

What is the Role RipTide WebVerse lab?

Role RipTide is an easy WebVerse web/API security lab focused on a real-world mass assignment vulnerability in a profile/account update endpoint.

The lab teaches how a normal user can escalate privileges by modifying a client-controlled JSON field (role) and then pivot into admin-only API functionality to retrieve sensitive data.

What vulnerability is demonstrated in Role RipTide?

Role RipTide demonstrates a mass assignment vulnerability (also closely related to BOPLA / Broken Object Property Level Authorization in API security contexts).

The backend accepts a user-supplied JSON object too broadly and allows a normal user to update the role field, which should be server-controlled.

Is Role RipTide an IDOR/BOLA lab or a mass assignment lab?

Role RipTide is primarily a mass assignment privilege escalation lab.

It has an AuthZ / IDOR-ish feel because the impact is unauthorized access to admin-only data, but the root cause is not direct object reference manipulation — it’s the backend trusting user-controlled properties during an account update.

What is mass assignment in web/API security?

Mass assignment happens when a server accepts a client-supplied object (often JSON) and automatically maps fields onto a backend model without strict allowlisting.

If sensitive properties are not blocked, attackers can set fields like:

  • role
  • is_admin
  • permissions
  • plan
  • account_status

In Role RipTide, changing "role": "user" to "role": "admin" is the core exploit.

What is BOPLA and how does it relate to Role RipTide?

BOPLA stands for Broken Object Property Level Authorization (an OWASP API Security concept).

It happens when an API exposes or accepts properties that the current user should not be able to read or modify. Role RipTide maps well to this idea because the API accepts a sensitive property (role) from an unprivileged user.

Why is hiding the role field in the UI not a real fix?

Hiding the role field in the frontend is not a security control because attackers can intercept and modify requests with tools like Burp Suite or a proxy.

The server must enforce which fields a user is allowed to update. If the backend accepts role from the client, the user can still send it manually even if the UI never shows it.

Why might I need to re-login after changing the role to admin?

It depends on how the app handles authorization:

  • If the role is checked from the database on each request, the change may apply immediately.
  • If the role is embedded in a session token or JWT, you may need to log out and log back in so a new token reflects the updated role.

Role RipTide helps reinforce this common real-world behavior.

How do you find the admin API endpoints after privilege escalation?

After gaining admin access, the best next step is to use the browser Network tab (DevTools) and refresh admin pages to see which API routes the frontend calls.

From there, you can perform endpoint enumeration / fuzzing on the admin API prefix (such as /api/v1/admin/) to discover additional routes like config.

Why is admin API endpoint fuzzing useful in this lab?

Admin UIs often act like thin clients and only expose a subset of backend functionality in the visible interface.

By fuzzing the admin API path after privilege escalation, you can discover endpoints that are not directly linked in the UI but still exist on the server — including sensitive configuration routes that may expose secrets or flags.

What does Role RipTide teach about exploit chaining?

Role RipTide teaches a simple but realistic exploit chain:

  • profile update request interception
  • mass assignment privilege escalation (role=admin)
  • admin-only page access
  • browser-based API recon (Network tab)
  • admin endpoint fuzzing
  • sensitive config retrieval via admin API

It’s a great intro to how authorization flaws and API recon combine in real web applications.

How should developers prevent mass assignment vulnerabilities like this?

The most effective defenses are:

  • strict server-side field allowlists for profile updates
  • separate DTOs/schemas for user-editable fields
  • never trusting client-supplied privilege fields (role, is_admin, etc.)
  • authorization checks on all admin routes and sensitive APIs
  • logging and monitoring for permission or role changes

Can I practice Role RipTide and similar labs online?

Yes — you can practice Role RipTide and other WebVerse web and API security labs at webverselabs.com.

WebVerse provides hands-on labs for mass assignment, API authorization flaws, information disclosure, and multi-step web/API exploit chains.

Read more