# Hacking with Docs: Finding a Critical API Vulnerability via Documentation

> *Sometimes, the best vulnerabilities aren’t found with brute-force, fuzzing or fancy payloads they’re hiding in plain sight, right inside the documentation.*

While testing a private program on HackerOne — let’s call it [`target.dev`](http://target.dev) . I came across a platform designed to manage **organizations and teams**. The functionality was quite structured:

* An **organization admin** could invite team members and assign roles like **admin** or **member**.
    
* There was a feature to generate **API tokens** with **scoped permissions** for example, a token that could manage teams but not the organization itself.
    
* The best part? The target had **public API documentation** showing exactly how to use the token with different endpoints.
    
* If you're testing an app that allows users to **create or generate API tokens**, take time to:
    
    * **Explore the full API documentation**, especially looking for different **API versions (like** `/v1`, `/v2`, `/v3`, etc.).
        
    * Understand what each token can access, especially the **scope or permission model**.
        
    * Cross-check documented endpoints with live behavior and don’t stop at what’s written.
        
    
    Sometimes, the gap between documentation and implementation is where bugs live.
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1752730483790/3b5eca33-a787-4a4a-8f55-7436f25bd8eb.png align="center")
    

The API docs clearly laid out endpoints like:

* `GET /api/v3/<orgid>/users` – list team members
    
* `POST /api/v3/<orgid>/users` – invite a new team member
    
* `PATCH /api/v3/<orgid>/users/<userid>` – update a team member
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1752730405560/5a9654ce-faa6-448b-a27f-fbb4bf37962f.png align="center")

All of these endpoints **respected the token’s assigned permissions**. I had a token created with the permission to **only manage teams**, not the full organization. When I tested those three endpoints, everything worked exactly as expected: **access denied** for anything outside the allowed scope.

But then I thought: ***What about undocumented or unmentioned HTTP methods?***

I took the same endpoint path and simply tried:  
`/api/v3/<orgid>/users/<userid>`

```bash
DELETE /api/v3/<orgid>/users/<userid>
```

> **To my surprise…It worked out of the blue.**

Despite having a token with limited permissions, I was able to **delete any user** from the team **including the organization admin**.

### Why This Was Critical

* The DELETE method was **not documented** anywhere in the official API docs.
    
* The token I used was never intended to perform destructive actions like removing members.
    
* An attacker with such a token could remove all admins, lock out legitimate users.
    

I reported the issue to the program through HackerOne. The team responded quickly, **acknowledged the vulnerability**, and **fixed it** by updating access control on the `DELETE` method and **improving the API documentation** to avoid such blind spots in the future.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1752730707307/c1b162fd-111d-40dc-b1d7-06eb310ba411.png align="center")