Hi Guys,
I'm Karthikeyan.V, a passionate Ethical Hacker and Cyber Security Researcher. During the recent Pongal holidays, I visited my grandma's house to spend time with family. While helping her clean up her phone, I stumbled upon a message about paying her Chennai Metro Water tax. Curious, I clicked the link, and to my surprise, the page opened without any authentication, displaying her name, mobile number, address, and payment amount.
Initial Observation
This unexpected access to personal information caught my attention. Despite not having my laptop, I decided to investigate further using just my mobile phone. I noticed the URL didn't contain any visible parameters but had a short alphanumeric string appended to the domain, like:
One of the affected functionalities was the PDF receipt generation endpoint:
POST /svr/bnc-ms.php?makePdfReceipt=true
The request contained a customer-related identifier in the JSON body:
{
"id": "<CUSTOMER_ID>",
"is_print_cashier_label": false
}
For privacy and responsible disclosure reasons, I have replaced the original customer identifier with <CUSTOMER_ID>.
Digging Deeper
I investigated how the application handled the supplied customer identifier. The server processed the identifier and generated a PDF receipt associated with the referenced customer.
This raised an important security question: Does the application verify whether the requesting user is actually authorized to access that customer's bill?
During authorized testing, I changed the referenced object identifier and submitted the request again. The application returned a billing document belonging to a different customer, demonstrating an Insecure Direct Object Reference (IDOR) / Broken Object Level Authorization (BOLA) issue.
PDF Bill Exposure
The impact was more serious than simply accessing a customer ID. The vulnerable functionality could generate a PDF bill/receipt associated with another customer's account.
Depending on the customer's bill, the document could contain sensitive information such as:
- Customer name
- Address
- Mobile number
- Customer/account information
- Billing information
- Connection-related information
All real customer information has been removed or redacted from this public write-up.
Another IDOR Vulnerability
While investigating the application further, I identified another customer-related endpoint used by the quick-payment functionality:
POST /svr/bnc-ms.php?verifyQuickPayCusID=true
The request contained a customer identifier:
{
"enc_cus_id": "<CUSTOMER_ID>"
}
During authorized testing, modifying the referenced customer identifier resulted in information associated with another customer being returned without an appropriate authorization check.
What is IDOR?
Insecure Direct Object Reference (IDOR) is a vulnerability that occurs when an application uses a user-controlled identifier to access an internal object without properly verifying whether the user is authorized to access that object.
In this case, the application accepted a customer-related identifier and processed the corresponding resource without adequately validating whether the requester had permission to access that customer's information.
Security Impact
Successful exploitation could allow an unauthorized user to access information belonging to other customers. The PDF bill functionality could also expose customer billing documents.
Potentially exposed information included:
- Customer names
- Mobile numbers
- Addresses
- Billing information
- Customer/account identifiers
- PDF bills or receipts
Exposure of this information could also increase the risk of social engineering and fraudulent payment attempts by attackers impersonating a legitimate water-service provider.
POC 1 IDOR
POC 2 IDOR PDF receipt generation
Reporting the Vulnerability
After confirming the issue, I documented the vulnerabilities and prepared a detailed Proof of Concept (PoC) for responsible disclosure.
I limited my testing to the minimum required to demonstrate the security impact and did not intentionally collect or retain unnecessary customer information.
Recommended Fix
The application should implement strict server-side authorization checks for every customer-related request.
Before returning a customer record or generating a PDF bill, the server should verify:
Authenticated User
↓
Is the user authorized?
↓
Requested Customer ID
↓
Return resource only if authorized
Simply hiding, encoding, or encrypting customer IDs is not sufficient. Authorization must be enforced on the server for every requested object.
Final Thoughts
This research highlights why authorization checks are extremely important for applications that process sensitive customer and billing information.
An identifier should never be treated as proof that a user is authorized to access the corresponding resource.
Disclaimer
This write-up is intended for educational purposes and responsible security research. I have intentionally removed customer identifiers, personal information, and other sensitive details from the public PoC to protect user privacy.
Do not attempt to access or download another person's information or documents without explicit authorization.
Purpose of This Write-Up
My intention in sharing this research is to raise awareness about IDOR/BOLA vulnerabilities and emphasize the importance of implementing proper server-side authorization controls.
Together, we can help build safer and more secure applications.
LEARN MORE — PROFESSIONAL COURSES
If you want hands-on training (mobile & web bug bounty and API Bugbounty / VAPT), check out our certified courses — real apps, real bugs, live labs.
🔥 Limited-Time Offer: ₹5,500 course now at just ₹2,500!
Enroll / Learn more: https://university.cappriciosec.com/CMABP.html
🔥 Limited-Time Offer: ₹7,999 course now at just ₹1,499!
Enroll / Learn more: https://karthithehacker.com/best-bug-bounty-web-penetration-testing-course-tamil.html
🔥 Limited-Time Offer: ₹7,999 course now at just ₹5,999!
Enroll / Learn more: https://university.cappriciosec.com/CAPBB.html
What you get
- Live, hands-on pentesting on real applications — not simulated labs.
- Comprehensive curriculum — web & mobile security fundamentals, OAuth, redirect handling, PKCE, secure coding and remediation guidance.
- Real-world case studies (responsibly redacted) and POC walkthroughs.
- Career & bounty guidance — report writing, disclosure, and monetization of findings.
- Final certification & lifetime access to recordings.
