When Deleting the Default Workspace Made the Entire Account Unusable

While testing a web application for broken access control issues, I came across an interesting case where a workspace that was supposed to be protected could still be deleted by manipulating the workspace ID.

What initially looked like a simple frontend restriction turned into a backend authorization issue that could make the affected account practically unusable.

The report was later validated by the company, and the finding was recognized on their Hall of Fame page. 🏆

👋 Whoami

Hi everyone! I'm Ankit Rathva aka Gujarati Hacker, a security researcher and bug bounty hunter who enjoys finding vulnerabilities in web applications. 🕵️‍♂️🔐

I mainly focus on areas such as:

• 🔐 Authentication & Authorization
• 🚪 Broken Access Control
• 🧠 Business Logic Vulnerabilities
• 🔄 Race Conditions
• 👤 Account Takeover
• 🌐 Web Application Security

For me, bug bounty hunting isn't just about finding a bug. It's about understanding how an application is supposed to work, where its security boundaries are, and what happens when those boundaries are tested in unexpected ways.

I spend a lot of time testing situations where the frontend says one thing, but the backend behaves differently.

And that's exactly what happened here.

🔎 What I Found

The application had a workspace called "Default Workspace."

From the normal user interface, this workspace was protected and could not be deleted.

That immediately made me curious:

Is the restriction actually enforced by the backend, or is it only a frontend restriction?

This is one of the things I always keep in mind while testing authorization:

Never assume that something is protected just because the UI doesn't allow you to perform an action.

So I started looking at the actual API request.

🏗️ Understanding the Workspace Deletion Flow

First, I created another workspace called:

test

The account now contained multiple workspaces, including:

• Default Workspace
• test

I could normally delete the test workspace.

When I captured the deletion request in Burp Suite, I noticed that the workspace ID was directly included in the request.

The request looked conceptually like:

GET /customer-service/workspace/v1/delete-workspace/{workspace_id}

GET /customer-service/workspace/v1/delete-workspace/{workspace_id}

The interesting part was the {workspace_id}.

The server was receiving the workspace ID directly from the client.

🧪 Testing the Protected Workspace

I then tried deleting the Default Workspace through the normal interface.

The application didn't provide an option to delete it.

At this point, it would have been easy to stop testing.

But the frontend restriction wasn't enough evidence that the backend was secure.

So I captured a legitimate workspace deletion request using Burp Suite.

Instead of changing anything else, I modified only the workspace ID.

Original request

GET /customer-service/workspace/v1/delete-workspace/<test_workspace_id>

GET /customer-service/workspace/v1/delete-workspace/<test_workspace_id>

Modified request

GET /customer-service/workspace/v1/delete-workspace/<default_workspace_id>

GET /customer-service/workspace/v1/delete-workspace/<default_workspace_id>

I forwarded the request.

And the server returned:

200 OK

200 OK

The protected workspace had been deleted.

💥 The Interesting Part: The Application Broke

The issue wasn't limited to deleting a workspace that the UI considered protected.

After deleting the Default Workspace, the application entered an unexpected state.

The other workspaces became inaccessible.

The application displayed a blank page.

When I attempted to log in again, the application became stuck on:

https://target.com/loading

https://target.com/loading

So the result wasn't simply:

"A user can delete a protected workspace."

The deletion appeared to break the normal workspace/account flow.

The application seemed to rely on the existence of the Default Workspace, but the backend didn't prevent its deletion or properly handle the situation afterward.

🔥 Impact

An authenticated user could manipulate the workspace ID in a legitimate deletion request and delete a workspace that was intended to be protected.

The resulting impact included:

• Protected Default Workspace deletion
• Loss of access to other workspaces
• Blank application state
• Login flow becoming stuck on the loading page
• Potential denial of service against the affected account/workspace environment

The most interesting part for me was that the vulnerability crossed the boundary between a simple authorization bypass and a business-logic failure.

The attacker wasn't just deleting an ordinary workspace.

They were deleting an object that the application appeared to depend on.

📩 Reporting the Vulnerability

The company investigated the report and validated the vulnerability.

Later, the finding was also recognized on the company's Hall of Fame page. 🏆

That was a great confirmation that the testing methodology and impact were valid.

🙏 Thanks for Reading!

If you enjoy practical web application security and bug bounty write-ups, follow me for more vulnerability research, methodology, and real-world findings. 🚀

🔐 Keep Hunting. Keep Learning. Keep Securing.

#BugBounty #CyberSecurity #WebSecurity #BugBountyHunter #BrokenAccessControl #IDOR #WebApplicationSecurity #EthicalHacking #BurpSuite #SecurityResearch