The Optus Data Breach Explained: 10 Million Records Stolen Through IDOR Vulnerability

TLDR: In September 2022, a hacker breached Optus — Australia's second-largest telco — and extracted the personal data of nearly 10 million customers. No malware. No zero-day exploit. They found an unprotected API endpoint, noticed the customer IDs were sequential integers, and wrote a loop. 1, 2, 3… all the way to roughly 10 million. Names, addresses, passport numbers, driver's licences. The Australian regulator confirmed it afterwards: "The attack was carried out through a simple process of trial and error." This is what IDOR looks like in the real world.

It Started With One API Request

The attacker found an API endpoint. It looked something like this:

GET https://api.www.optus.com.au/customer/details?contactId=1234

They sent the request. Customer data came back. No login required. No token. No verification that the person asking for record 1234 was actually the owner of record 1234.

So they changed 1234 to 1235. More data. Then 1236. Then they wrote a script and walked through every integer from 1 to roughly 10 million. Over three days — September 17 to September 20, 2022 — they pulled names, dates of birth, phone numbers, home addresses, email addresses, passport numbers, and driver's licence details for close to a third of Australia's entire population.

The Australian Communications and Media Authority (ACMA) investigated and concluded the attack "was not highly sophisticated or one that required advanced skills." It was trial and error. A loop counter.

What IDOR Actually Means

IDOR stands for Insecure Direct Object Reference. It sounds technical. The concept is not.

It means your application gives users a direct handle — an ID, a number, a filename — to access a resource, and then fails to check whether that user is allowed to access it.

The authentication question is: who are you? The authorisation question is: what are you allowed to access?

Optus's API had neither. Anyone on the internet could query it, and once they were in, there was no check at all on whose data they were requesting. These are two separate failures that compounded each other catastrophically.

The fix for IDOR is conceptually simple: every time your server receives a request for a resource, it needs to verify that the authenticated user actually owns that resource. Not just that they're logged in — that they own this specific record. That check was missing entirely.

What the Vulnerable Code Looks Like — and What It Should Look Like

Here is a simplified version of what went wrong:

# VULNERABLE — no ownership check
def get_customer_details(contact_id):
    customer = db.query("SELECT * FROM customers WHERE id = ?", contact_id)
    return customer  # Returns ANY customer's data to ANY caller

Here is what it should look like:

# SECURE — server-side ownership check
def get_customer_details(contact_id, authenticated_user):
    customer = db.query(
        "SELECT * FROM customers WHERE id = ? AND owner_id = ?",
        contact_id,
        authenticated_user.id  # Verify the requester owns this record
    )
    if not customer:
        return 403  # Forbidden — even if the record exists
    return customer

One extra condition. That's the entire difference between a secure endpoint and one that leaks 10 million records.

There's a second compounding issue: Optus used sequential integer IDs. If you have record 5000, it takes no imagination to guess that record 5001 exists. Using UUIDs (random, non-guessable identifiers like a7f3c912-b041-4d2e-9e3a-ff1c6d8e2b00) doesn't fix missing authorisation checks — but it removes the ability to enumerate records even if a check is bypassed.

Why This Is #1 on OWASP 2025

Broken Access Control — the category IDOR sits within — has been the number one web application vulnerability on the OWASP Top 10 since 2021, and it held that position in 2025. It appears in more tested applications than any other category by a wide margin.

The reason it's so persistent is that it's invisible to automated scanners. A scanner can tell you that an endpoint exists. It cannot tell you whether the logic inside that endpoint correctly verifies ownership. That requires a human tester who actually reads the code or probes the API the way an attacker would.

We've covered how frequently this pattern appears in real codebases in this post. It's not a rare edge case. It's what happens when developers focus on building features and no one has explicitly asked "can user A access user B's data through this endpoint?"

The Detail That Makes This Worse

The ACMA investigation revealed something that should make every engineering leader uncomfortable: the vulnerable API had been dormant since 2017. A developer introduced the access control coding error in 2018. Optus discovered and fixed the same error on their main domain in August 2021 — but didn't check whether the subdomain had the same issue.

It did. It sat there, internet-facing, unmonitored, unpatched, for another year.

The attacker didn't need internal knowledge. They didn't need special tools. They just needed to find a forgotten API endpoint that an organisation had lost track of. To avoid detection, they rotated through tens of thousands of IP addresses to mimic normal customer traffic patterns.

This is a pattern we see regularly when assessing API security for growing companies. Legacy endpoints. Test APIs never decommissioned. Subdomains that fell off the security team's radar after a restructure. Every one of them is a potential entry point.

Three Things You Can Check Today

You don't need a pen test to do a first-pass assessment. Here's what any developer or CTO can do this week:

1. Enumerate your own API endpoints. Do you have a complete inventory of every API endpoint your application exposes, including legacy ones? If you're not sure, an attacker will find out before you do.

2. Test horizontal access manually. Log in as User A. Note the ID of a resource you own. Log out. Log in as User B. Try to access User A's resource directly by its ID. If it returns data — you have an IDOR vulnerability.

3. Audit your IDs. Are you exposing sequential integer primary keys in your API responses and URLs? If so, switch to UUIDs for any externally exposed identifiers.

How Kuboid Secure Layer Can Help

IDOR vulnerabilities don't show up in automated scans. They show up when a security tester intentionally tries to access data they shouldn't own — the same way the Optus attacker did.

Our web application penetration tests specifically probe your API endpoints for broken access control, horizontal and vertical privilege escalation, and the kind of ownership logic failures that automated tooling misses entirely. We also review whether forgotten or legacy endpoints are still exposed.

If you want to know whether your application has the same pattern before someone else finds it, let's talk.

Has your team ever found an IDOR vulnerability in your own codebase — or caught one during a review? Drop a comment. You'd be surprised how common this pattern is even in mature engineering teams.

Kuboid Secure Layer provides web application penetration testing and API security assessments. Learn more at kuboid.in/services.

The Optus Data Breach Explained: 10 Million Records Stolen Through IDOR Vulnerability