Broken Authentication Vulnerability That Allowed Unauthorized Users to Like Private Posts

WhoAmI

I am Ankit Rathva and i am a student of MCA 2nd year, I am an ethical hacker and security researcher with a passion for finding logic, authorization, and data-integrity flaws in web applications. As a bug bounty hunter and red teamer, he combines hands-on testing, forensic analysis, and careful disclosure to help teams fix impactful issues while protecting users. He publishes clear, developer-friendly writeups and practical mitigation advice — connect to follow his work or collaborate on security research.

Connect with me: https://linkedin.com/in/ankitrathva

Overview

As a security researcher, I enjoy testing applications for logical flaws that could impact user privacy and security. Recently, while assessing a web application, I discovered an interesting Broken Authentication / Access Control issue that allowed an unauthorized user to interact with another user's private post.

Although the impact was limited, the finding highlighted an important security principle: if users cannot view a private resource, they should never be able to interact with it.

The security team acknowledged the report, classified it as Low Severity, and rewarded me with $$ for the responsible disclosure.

📌 Vulnerability Details

• 🛡️ Vulnerability Name: Broken Access Control
• 📋 Severity (Triaged): Low
• ✅ Status: Accepted
• 💵 Reward: $$

🧠 Understanding the Issue

The application allows users to create suggestion posts and mark them as Private. Once marked as private, these posts are intended to be accessible only by their owners.

While testing the application's functionality, I noticed that the Like feature relied only on the comment/post ID supplied in the request. The backend failed to verify whether the authenticated user actually had permission to interact with that private post.

As a result, an attacker could manipulate the request and successfully ❤️ Like another user's private post without having permission to access it.

This indicates a Broken Authentication / Authorization issue where proper server-side permission checks are missing.

🔍 Steps to Reproduce

📝 Step 1 — Create an Account

Register a new account and log into the application.

📂 Step 2 — Create a Board

Create a new board.

💡 Step 3 — Create a Private Suggestion

Click on Make Suggestions, create a new suggestion, and mark it as Private before submitting it.

After opening the post, you'll notice the ❤️ Like button.

Since the suggestion is private, only the owner should be able to interact with it.

👤 Step 4 — Create Another User

Create another account that will act as the attacker.

🕵️ Step 5 — Intercept the Request

Click the Like button on your own private suggestion while intercepting the request using Burp Suite.

✏️ Step 6 — Modify the Request

Replace the comment ID in the intercepted request with the ID of another user's private post.

Forward the modified request.

🚨 Step 7 — Result

🎯 The server accepts the modified request and records a Like on the victim's private post, even though the attacker has no permission to access or view that post.

This proves that the backend validates the request without verifying whether the authenticated user is authorized to perform the action.

⚠️ Impact

Although the vulnerability did not expose the contents of private posts, it still introduced several security concerns:

✅ Unauthorized users could interact with private posts.

📈 Private posts could receive unexpected engagement.

📊 Like counts become inconsistent and unreliable.

🔓 The issue demonstrates missing server-side authorization checks.

⚡ Similar authorization flaws could potentially exist in other sensitive endpoints.

🤔 Why Was It Classified as Low Severity?

The security team acknowledged the issue but assigned it a Low Severity rating.

The primary reason was that the private post IDs were long, unique, and difficult to predict, making practical exploitation significantly harder without already knowing a valid identifier.

While this reduces the likelihood of exploitation, security should never rely solely on unpredictable identifiers.

Proper authorization checks must always be enforced on the server.

_🔑 _Security through obscurity is never a substitute for proper access control.

🎯 Final Thoughts

This finding is another reminder that authentication alone is not enough — applications must also enforce authorization for every protected resource.

Even though the vulnerability was ultimately rated as Low Severity due to the difficulty of discovering valid private post IDs, it still exposed an important weakness in the application's access control logic.

Responsible disclosure helps organizations identify and fix these subtle issues before they can be chained with other vulnerabilities.

I'm happy that the company acknowledged my report and rewarded me with 💰 $$, proving that even lower-severity findings contribute to strengthening an application's overall security posture.

🙌 Thank You for Reading!

If you enjoyed this write-up, feel free to connect with me and follow my journey in Bug Bounty Hunting, Web Security, and Responsible Disclosure.

Happy Hunting! 🐞🚀