My name is Osama Mohamed, also known as Oxmorv.

In this write-up, I'll walk you through how I discovered an Insecure Direct Object Reference (IDOR) vulnerability that allowed me to delete spaces belonging to other users — spaces I had no authorization to access or modify.

Summary

While testing a public bug bounty program, I found that the GraphQL API endpoint responsible for deleting spaces fails to validate whether the requesting user has authorization over the target space. By decoding the Base64-encoded space ID, modifying the numeric value, and re-encoding it, an admin can delete any space on the platform — including those owned by the Owner role.

Discovery

While browsing the application, I noticed spaces have sequential numeric IDs visible in the URL:

https://target.com/spaces/1432434

My first instinct was to check if the ID was passed as plaintext in the deletion request. When I intercepted it in Burp Suite, I found something different:

json

{
  "query": "mutation deleteSpace($spaceId: ID!) {\n  deleteSpace(input: {spaceId: $spaceId}) {\n    errors {\n      message\n    }\n  }\n}",
  "variables": {
    "spaceId": "Z2lkOi8vZWxhaW5lL0J1bmRsZS8xNDMxNzg2"
  },
  "operationName": "deleteSpace"
}

The spaceId was Base64 encoded. Decoding it revealed:

gid://elaine/Bundle/1431786

This is a Global ID (GID) — a common pattern in GraphQL APIs with the format:

gid://<app_name>/<resource_type>/<numeric_id>

This meant I could target any space by simply encoding a different numeric ID in the same format.

Exploitation

I constructed a malicious spaceId by:

  1. Taking the GID format: gid://elaine/Bundle/<victim_space_id>
  2. Replacing the numeric ID with another user's space ID
  3. Base64 encoding the result
  4. Replacing the spaceId value in the intercepted request

When sent as an admin, the API deleted the target space with no errors — regardless of whether it belonged to a Member or even the Owner.

Steps to Reproduce

  1. Log in as an Admin user
  2. Navigate to any of your own spaces and click delete — intercept the request in Burp Suite
  3. Decode the spaceId value from Base64:
gid://elaine/Bundle/1431786
  1. Replace the numeric ID with a victim's space ID
  2. Re-encode the modified GID in Base64
  3. Replace the spaceId in the request and forward it
  4. The victim's space is permanently deleted ✓

Impact

An admin can permanently delete any space on the platform, including those owned by higher-privileged users such as the Owner. This results in:

  • Irreversible data loss for the victim
  • Full disruption of other users' workspaces
  • Privilege escalation beyond the intended admin role boundaries

Conclusion

The root cause is a missing server-side authorization check — the API trusts the encoded ID without verifying ownership. The fix is straightforward: before executing the deletion, the server must confirm that the requesting user has permission over the target space.

Thanks for reading — Osama Mohamed / Oxmorv