In this article, I’m sharing a firsthand account of an IDOR (Insecure Direct Object Reference) vulnerability discovered in the Casino Max app—a platform that lets Casino customers register their loyalty card, check promotions, add payment methods, and more. Under real-world conditions, this flaw made it possible to make in-store purchases without paying.

Introduction: How the Investigation Began

Casino Max is touted in Casino stores through enticing ads. Out of curiosity, I installed and studied the app with my usual audit tools (proxy, scripts, etc.). My initial goal: spot high-impact vulnerabilities with minimal effort. Often, this approach quickly unveils critical flaws, such as IDOR.

First Discovery: The verify-subscription Endpoint

After setting up the app and configuring my proxy to intercept requests, I discovered an interesting endpoint:

/v1/user/verify-subscription/<id/email>

• Endpoint Purpose: Check the existence or status of an account (or loyalty card), either by a loyalty card ID or an email address.
• Response: A highly verbose JSON that includes fields like:
  • is_activated (true/false)
  • has_password (true/false)
  • has_birthdate (true/false)
  • first_name
  • last_name
  • first_connexion
  • fid (loyalty card number)

Hint: The fact that first_name and last_name are exposed without authentication is a major red flag. It allows an attacker to easily validate or refine a list of email addresses or loyalty card numbers and retrieve personal data in the process.

Understanding the IDOR Vulnerability

An IDOR (Insecure Direct Object Reference) occurs when an application fails to properly verify access rights to a resource (like a loyalty account or an email address), enabling a malicious user to view or manipulate data they shouldn’t have access to.

In Casino Max, it was possible to query the endpoint directly using various loyalty card IDs or email addresses and receive sensitive information, with no robust access control preventing it.

Technical Exploitation: Scripts and Complementary Endpoints

1. Information Gathering

I created a very basic Python script to automate calls to the verify-subscription endpoint, iterating over a list of loyalty card IDs or email addresses (obtained via simple enumeration or light brute force). The responses contained details like:

• Whether the card was activated or not.
• Whether a password was set.
• Personal information (first name, last name, etc.).

2. Attempting to Add Loyalty Cards

Within Casino Max, users can add a loyalty card to their account. Naturally, I wondered if I could link someone else’s card to my account. The first attempts failed, as the app appeared to check whether the card was already registered.

3. Side Avenue: The macartecasino.fr Site

Continuing my investigation, I stumbled upon another service:

https://www.macartecasino.fr/espace-carte/activation/

Hint: This site allows users to activate a loyalty card by providing the card number and a birthdate. If a card wasn’t activated yet, just providing those two pieces of info was enough to finalize activation. Once activated this way, the card was deemed “valid” to Casino Max.

4. Back to the App

After activation, I added the newly “legitimate” card in Casino Max. This granted me access to:

• The balance on that card (if any).
• The transaction history associated with it.

Lack of authentication or strict checks on the card’s data made this process surprisingly easy.

Real-World Test: In-Store Verification

To confirm that the attack actually worked in a live setting, I visited a Casino store. At the self-checkout, you can tap “loyalty card” and scan the barcode shown in the Casino Max app.

Result:

• I was able to complete my checkout without the app charging me a dime.
• I walked out with my items without paying anything, as the transaction was considered settled by the linked card.

Of course, this demonstration served only to prove the vulnerability rather than to cause any harm.

Disclosure and Bounty

In line with ethical hacking best practices, I submitted a detailed report through a private bug bounty program. Casino acknowledged the critical nature of the flaw, fixed the vulnerability, and provided an appropriate reward.

• CVSS Score: 7.5

Conclusion: Key Takeaways

This experience underscores how even a large-scale retail application—presumably well-tested—can contain critical flaws. Highlights include:

1. Insufficiently Protected Activation Systems: A simple card number + birthdate combo is easy to guess or harvest.
2. Minimal Access Verification: The IDOR permitted retrieval or validation of sensitive info (name, last name, card status) without authentication.
3. Real-World Impact: The exploit allowed not only data exposure but also direct fraudulent use in-store.

Ultimately, this breach serves as a reminder that security can never be taken for granted. Strict access controls, less verbose server responses, and more rigorous server-side validations are essential to prevent such abuses.