Lab 251 — PulseBoard — IDOR via Unauthenticated GraphQL User Profile Query

Platform: CUSTOM | Category: Web | Type: Challenge | Difficulty: Easy | OS: N/A | **Author: XESXOR Techniques: graphql_introspection, idor_exploitation, sensitive_field_extraction, user_enumeration

Summary

Walkthrough of the CUSTOM Web Lab 251 — PulseBoard — IDOR via Unauthenticated GraphQL User Profile Query. Task: PulseBoard GraphQL API exposes getUserProfile(userId) query without authentication. Solution: enumerate schema via introspection, query admin user (ID 1) to extract flag from internalNotes field

Description

PulseBoard is a team analytics and workspace management platform built by PulseMetrics Inc. It features user dashboards, team management, project metrics, and a modern GraphQL API layer. The platform serves multiple teams with different permission levels.

Your objective is to find sensitive information that should only be accessible to administrators. Explore the application's API surface carefully — not all endpoints enforce the same level of access control.

The application uses a GraphQL API to power its frontend. Pay attention to how data is fetched and whether proper authorization is enforced on all queries. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

English summary: PulseBoard is a team analytics platform with a GraphQL API. The goal is to find sensitive admin data by exploiting improper access control on API queries.

Summary

The challenge demonstrates a classic IDOR (Insecure Direct Object Reference) vulnerability in a GraphQL API. The getUserProfile(userId) query accepts any user ID and returns sensitive user data including internal notes — without requiring authentication. By querying the admin user (ID 1), the flag was retrieved from the internalNotes field. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Recon

1. Discovered GraphQL endpoint at /graphql with introspection enabled

2. Enumerated the schema using introspection queries:

   • Available queries: getUserProfile, getTeamMembers, getTeams, getProjects, me
   • getUserProfile(userId: Int!) takes a userId parameter — potential IDOR
   • User type has fields: id, username, email, role, phone, avatar, createdAt, internalNotes

3. Key observation: The internalNotes field on the User type suggests sensitive data that should be protected ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Vulnerability

The root cause is a combination of three security flaws in the getUserProfile GraphQL query:

1. No authentication required — the query could be called without logging in
2. No authorization check — any userId could be queried by anyone
3. Sensitive data exposure — returned internalNotes field containing admin secrets

Expected behavior:

• The query should require authentication
• Users should only be able to query their own profile, or have role-based access control
• Sensitive fields like internalNotes should be restricted to admins only ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Actual behavior:

• Anyone can query any user's profile including sensitive internal notes without authentication

Exploitation

Exploited the IDOR by querying the admin user (ID 1) without authentication:

 bash read-only • copy allowed Copy
curl -s "https://e43a73e1-5aea-40d3-9966-9fedcccadccc.labs.hackadvisor.io/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ getUserProfile(userId: 1) { id username email role internalNotes } }"}'

Response revealed admin's sensitive data:

 json read-only • copy allowed Copy
{
  "data": {
    "getUserProfile": {
      "id": 1,
      "username": "carolyn.blackwell",
      "email": "admin@pulsemetrics.com",
      "role": "admin",
      "internalNotes": "FLAG{REDACTED}"
    }
  }
}

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Remediation

• Require authentication for all GraphQL queries that return user data
• Implement object-level authorization: users should only access their own profile unless they have admin privileges
• Remove or restrict sensitive fields like internalNotes from the GraphQL schema, or implement field-level authorization
• Disable GraphQL introspection in production environments
• Add rate limiting to prevent enumeration attacks ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Key Takeaways / Lessons

• Mastering graphql_introspection, idor_exploitation, sensitive_field_extraction, user_enumeration was key to this challenge.
• Always check for common misconfigurations and verify assumptions.

---

Crafted by XESXOR Research • 2026-04-27 • CUSTOM • Lab 251 — PulseBoard — IDOR via Unauthenticated GraphQL User Profile Query • Difficulty: Easy