ÉduConnect Breach: 7.2M School Records via IDOR

What Happened: A Embarrassingly Simple Vulnerability

In late April 2026, an IDOR vulnerability (Insecure Direct Object Reference) discovered on ÉduConnect — France's national authentication portal used by families to access school services — led to the exfiltration of 7.2 million school report cards. The attack required zero sophisticated tooling: an attacker simply incremented a numeric ID in an API URL to access another student's records.

A request like:

GET /api/bulletins?eleve_id=1042837

became:

GET /api/bulletins?eleve_id=1042838

The server responded with the next student's full data — name, school, grades, teacher comments — with no check that the authenticated session actually owned that record.

Why IDOR Is the Most Underestimated Web Vulnerability

IDOR has been in the OWASP Top 10 for years (A01:2021 – Broken Access Control), yet it remains one of the most frequently exploited vulnerabilities in production systems. The reason is straightforward: it's not a complex code bug — it's an architectural oversight. The server fails to verify that user A is actually authorized to access resource B.

ÉduConnect's API trusted the client-supplied identifier without cross-referencing the authenticated session's identity. This is a classic pattern found in thousands of applications — especially those built quickly with Laravel, Django, Express, or no-code platforms where access control is often bolted on as an afterthought.

The Scale of Exposed Data

Based on initial disclosures, the accessible data included:

• Full name and date of birth of students
• School name (middle school, high school)
• Complete report cards with subject grades and teacher assessments
• Legal guardian contact information in some cases

This is particularly sensitive under GDPR because the subjects are minors. France's data protection authority (CNIL) has opened a formal investigation. The Ministry of National Education confirmed the incident and stated the breach had been patched, without disclosing how long the API had been exposed.

Early reports indicate the exfiltration was automated via a script sequentially iterating over IDs — trivial to write, devastatingly effective when no rate limiting is in place.

Why Your Own Projects Are Probably at Risk

Whether you're building a SaaS, a custom Shopify app, a WordPress plugin, or a no-code project, here are the at-risk patterns to watch:

Pattern 1: Sequential IDs exposed in URLs

/orders/10542
/invoices/88721
/profile/edit/3301

If these IDs are predictable and your backend doesn't verify resource ownership, you're vulnerable.

Pattern 2: REST APIs without ownership checks

// ❌ Vulnerable
app.get('/api/documents/:id', async (req, res) => {
  const doc = await Document.findById(req.params.id);
  res.json(doc);
});

// ✅ Safe
app.get('/api/documents/:id', async (req, res) => {
  const doc = await Document.findOne({
    _id: req.params.id,
    owner: req.user.id  // ownership check
  });
  if (!doc) return res.status(403).json({ error: 'Forbidden' });
  res.json(doc);
});

Pattern 3: UUIDs as a false sense of security Many developers assume switching to UUIDs (e.g., /api/records/f47ac10b-58cc-4372-a567-0e02b2c3d479) solves the problem. It doesn't. If the server doesn't check authorization, an attacker who obtains a valid UUID through any other vector can still access the resource.

What Automated Testing Catches (and What It Misses)

Traditional security scanners struggle with IDOR because the vulnerability is contextual — it depends on the relationship between users and resources. An effective scanner must:

1. Authenticate with multiple distinct user accounts
2. Harvest resource identifiers belonging to one account
3. Attempt to access those resources from a second account
4. Compare responses to detect unauthorized access

This is precisely how Scorra approaches IDOR detection. By simulating multiple user sessions, Scorra automatically identifies endpoints where resources from one account are reachable from another. On an application like ÉduConnect, this test class would have flagged the vulnerability before it ever reached production.

The Real Cost for Developers and Businesses

For a government portal, the fallout is political and regulatory. For a startup or indie SaaS, a single IDOR vulnerability can mean:

• GDPR fines up to 4% of global annual turnover or €20M
• Mandatory breach notification within 72 hours of discovery (GDPR Article 33)
• Customer churn once the breach becomes public
• Personal liability for the developer who shipped the code in some jurisdictions

The ÉduConnect breach is a reminder that Broken Access Control isn't just an enterprise problem. It's a default risk in any application where multiple users access their own data.

Practical Defense Checklist

1. Audit every endpoint that accepts a resource identifier as a parameter
2. Enforce server-side ownership checks — never trust the client to tell you who owns what
3. Enable rate limiting on all API endpoints to make enumeration expensive
4. Log anomalous access patterns: a user iterating over hundreds of IDs in seconds should trigger an alert
5. Write cross-account test cases: your test suite must include scenarios where user A tries to access user B's resources
6. Use opaque identifiers (UUIDs or hashed IDs) as a defense-in-depth measure — not as a primary control

---

The ÉduConnect incident proves a principle every developer should internalize: the most damaging vulnerabilities aren't always the most sophisticated ones. Incrementing a number in a URL was enough to expose the school records of millions of French children.

Scan your APIs before someone else does. Run a free scan at scorra.io →