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 . 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.

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

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>

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.