Solving a Bugforge Daily Challenge (Feb 28) — Exploiting Hidden API Endpoint in Ottergram

Today, I solved the February 28 daily challenge on Bugforge, targeting a social-style web application called Ottergram.

The application allowed users to:

• Create an account
• Post photos
• Like posts
• Comment on posts

At first glance, it appeared to be a standard social media platform challenge. However, deeper exploration revealed a hidden API endpoint left exposed by the developer.

Initial Exploration

After registering and logging in, I tested:

• Posting images
• Liking posts
• Adding comments
• Viewing comment sections

Everything seemed properly functional from the UI perspective.

But in security testing, hidden functionality often exists beyond the frontend interface.

So I began inspecting network traffic and exploring possible API routes.

For this, I used:

• Caido

Discovering the Hidden Endpoint

While analyzing requests related to comments, I noticed a pattern in the API structure.

Although the UI did not provide an option to edit comments, I discovered an accessible endpoint structured like:

/api/post/{post_id}/comment/{comment_id}

This endpoint was not linked anywhere in the frontend — it appeared to be a leftover developer route.

That was suspicious.

Testing the Endpoint

By sending a request to this endpoint manually, I confirmed it was accessible.

More importantly:

• It accepted the PUT method
• It allowed updating comment content
• It did not properly validate ownership

This meant I could modify any comment by simply knowing its comment_id.

Exploitation Process

Step 1: Identify Target Comment

Found a comment associated with a post by analysing the POST request and getting comment_id.

Step 2: Craft PUT Request

Sent a PUT request to:

/api/post/{post_id}/comment/{comment_id}

With modified content in the request body.

Step 3: Forward Request

The server processed the update successfully.

The response returned the flag.

This confirmed a Broken Access Control vulnerability via hidden API endpoint exposure.

Why This Worked

The vulnerability existed because:

• A developer endpoint was left exposed
• The route was not protected by proper authorization checks
• Ownership validation was missing
• The frontend did not expose it — but the backend allowed it

Security through obscurity (hiding functionality in the UI) is not real security.

Security Lessons Learned

This challenge highlights important real-world lessons:

• Hidden endpoints must still enforce strict authorization
• Backend access control must not rely on frontend visibility
• Always validate resource ownership before allowing updates
• Remove unused or testing endpoints before deployment

APIs often expose more attack surface than the visible UI suggests.

Final Thoughts

This Bugforge daily challenge reinforced a powerful concept: If an endpoint exists, it must be secured — even if users cannot see it.

Hidden or undocumented API routes are common sources of vulnerabilities in real-world applications.

Careful API exploration and manual testing revealed what the UI tried to hide.