Investigating IDOR vulnerabilities in a BSE-listed company

18 Apr, 2026

NOTE: The article is ONLY a white-hat attempt and a technical Proof-of-Concept (POC) to investigate lax data security in web portals. NO data has been retained, or misused, for any non-authorized activities whatsoever. The concerned agency has been notified of the vulnerability following safe disclosure practices.

I don't particularly call myself a cybersecurity specialist. My professional interests lie closely aligned to data. But it is imperative that when one deals with data — especially ones containing Personally Identifiable Information (PII) — one must understand the ramifications of mishandling the data and the consequences that can come with it.

So, when I found out about this critical data leakage from a travel agency that also happens to be listed on the Stock Exchange in India (Bombay Stock Exchange - BSE), I was shell-shocked. Not only did it expose the PII of its customers but also revealed the transactional value in real-time, and the market segments that it operates on.

It is needless to say that the entire exercise is done purely in good faith — with only white-hat interests — all data that was obtained was subsequently wiped clean. I am also consciously choosing to avoid naming the agency as I do not want any malicious actors to target them using the exploit mechanism.

Overview: Setting the Context

I love to travel. There are certain travel plans that I've made for later this year, and the logistics of the same are being handled by this particular agency. I have an agreed upon payment schedule with them. Whenever I make a payment, the agency issues an automated invoice with an identifier (MR No) and tags my case to a specific Enquiry ID. Given below is an actual invoice that they share across (redacted for privacy):

This link is shared across in the format given below with the customer, to download the invoice. Do note that there is no other authentication mechanism involved and the invoice is publicly accessible.

https://<agency-website>.com/<api_version>/invoice.php?mr_id=<encoded-string>

Note the variable. This is the point where the whole leak unfurls.

The Intuition: Something's Wrong, Somewhere

I made my third installment payment to them on schedule, and as expected got an invoice download URL. As an engineer — and more so, for someone in data — I'm trained to look and analyze for patterns that other people might mostly miss. This is where the encoded string caught my eye. I knew at the back of my mind that there had to be some encoding logic to that invoice identifier. The good part was — I now already had three solid examples to map against.

So — what do you think the pattern is?

To be fair, it is not something that comes to mind in one shot. But here is where Claude enters. LLMs are exceptionally good at pattern recognition, and I decided to put Anthropic's Sonnet 4.6 to the test. I asked it to identify a pattern to these MR No -> Encoded String translations. Guess what — it came back with a solid answer.

This was a HUGE milestone! What Claude returned was astonishing. The encoder logic was two-way: meaning the string could also be decoded back to the original invoice number. We'll shortly understand why this is a vulnerability.

Data Extraction & Analysis

Now that we knew the encoder logic, we had to make it reusable. I made a generic Python function out of the logic obtained in the earlier stage:

import base64

def encode_value(identifier: int) -> str:
    decoded = identifier - 22802
    return base64.b64encode(str(decoded).encode()).decode()

The other vulnerability in the design was that all these Invoice IDs were sequentially numbered. Meaning if an invoice is numbered 100, the preceding invoice issued was 99 and the next one would be 101. This becomes all the more important because it makes the entire data indexable by a simple pattern querying. That is exactly what I applied. Once I had the encoded string, I appended that to the Base URL to obtain the download link.

BASE_URL = "https://<agency-website>.com/<api_version>/invoice.php?mr_id="

def get_invoice_url(identifier: int) -> str:
    return BASE_URL + encode_value(identifier)

def download_invoices(start_mr_id: int, end_mr_id: int, output_dir: str) -> None:
    for mr_id in range(start_mr_id, end_mr_id + 1):
        url = get_invoice_url(mr_id)
        response = requests.get(url)
        if response.status_code == 200 and response.headers.get('Content-Type', '').startswith('application/pdf'):
            file_path = f"{output_dir}/invoice_{mr_id}.pdf"
            with open(file_path, "wb") as f:
                f.write(response.content)

This is a classic Insecure Direct Object Reference (IDOR) vulnerability. The last step in the journey was to extract the fields from the PDF for each invoice issued. Given that the PDF had a rigid structure to it, it was relatively easy to extract the fields by using Regular Expressions (RegEx) calls.

The whole script was executed from the serverless Google Colab platform. I limited the data extraction to only ~100 invoices for Proof-of-Concept purposes. In theory, of course, you can extract all invoices out of their systems, which is unimaginable in modern security designs.

A snip of the parsed data is given below:

Insights

This limited schema of data exposed is alone to profile the company in multiple ways. For propriety, I've de-sensitized the data and implemented an ordinal swap for actual destination categories that the agency serves.

1. Market share determination: By bucketing the route/segment pair with the cash inflow (via invoice summation), it is easy to figure out where the agency really dominates and where they're still finding their feet. Clearly, as in the snip given below, a particular category far outcompetes the other lines they offer.

2. Revenue over time: Given both the cash inflow and the date is available if all invoices over time are extracted, it shouldn't be too hard to estimate the company's revenue as the inflow is a strong proxy indicator for growth and sales. This can also lead to extraction of seasonality insights for competitors, and strategic discounting techniques employed by the agency for customer acquisition can also be gamed by other players.

3. Proxy for future performance in the Stock Market: Given the invoices essentially serve as an indicator of the financial performance, a fundamental analysis can be arrived at earlier than the company's financial reports are put out to the public. This can be exploited by traders to make money with the insider knowledge.

4. Customer patterns: As customer information is openly available in the dataset alongside their payment behavior, a good statistical model can output detailed behavioral analysis for individuals. This includes detecting loyal customers, figuring out the churn rate, etc. Taken to an extreme, this could also lead to pattern mining on the credit profiles of these customers. Again, a competitor could leverage this information to win over them with better deals.

Potential Fixes

The core vulnerability here is that the encoding function is trivial and is easily reversable. To be truly secure (and un-crackable), strong encryption algorithms are preferred.

One could consider the AES standard (Advanced Encryption Standard). This function hashes the identifier with a private key that is only known to the agency. This would make it mathematically impossible to crack if the attacker does not possess the key.

Another possible alternative is to add a random salt value to each identifier and store it in a backend lookup table before encoding it. This would also play a similar role, where unless the attacker knows the salt, it is extremely hard to crack the same.

Ramifications

The case study undertaken is one of many such cases where lax security on web portals lead to data leaks. Under the newly framed Data Protection laws in India, data breaches invite heavy penalty and reporting compliances are strict.

If we zoom out into the larger picture, it is only getting easier for hackers to execute malicious intent on their targets with AI crunching massive datasets and performing pattern recognition activities. It is thereby imperative that all companies — especially the ones dealing with PII — perform periodic cybersecurity audits to be ahead of themselves (and the hackers).

Responsible Disclosure

The vulnerability has been proactively disclosed to the concerned agency prior to the publication of this analysis. Specific details to reproduce the issue, and potential fixes have been shared to the technical teams.