I fixed a cross-tenant data leak in our quiz system today.
Four lines of code. That's all it took. A quiz shortcode processor was fetching quizzes by ID without checking whether the quiz belonged to the requesting tenant's site. Any tenant could embed another tenant's quiz — exposing questions, answer options, and lead IDs across customer boundaries.
The fix was trivial: validate that the quiz's site ID matches the current request's site ID. Return a generic "not found" if it doesn't. Done.
But the vulnerability pattern it represents? That's not trivial at all.
Broken Access Control Is the #1 Security Risk. Again.
OWASP released their 2025 Top 10 last year. Broken Access Control held the #1 position — same as 2021. Their testing data is stark:
100% of tested applications had some form of broken access control vulnerability.
That's not a typo. Across 2.8 million applications tested, every single one had access control weaknesses. The specific subcategory we fixed — IDOR (Insecure Direct Object Reference) — is one of the most common forms.
On HackerOne, over 200 IDOR vulnerabilities are found and safely reported every month. IDOR-related reports grew 29% year-over-year. Bug bounty payouts for access control issues increased 23%.
This isn't a niche problem. It's the most common class of web application vulnerability, and it's getting worse.
Customer Education Platforms Are Particularly Exposed
Here's what makes customer education platforms different from your typical SaaS app: the data they handle.
A customer education platform stores:
Quiz responses — what your customers' employees answered, including open-text fields
Learning progress — which courses were completed, which were abandoned
Assessment results — pass/fail rates, scores, attempts
Lead capture data — names, emails, intent signals from optin forms
Completion certificates — evidence of competency, sometimes compliance-relevant
In a multi-tenant SaaS platform, all of this lives in shared infrastructure. The database, the application layer, the file storage — it's all shared. Tenant isolation happens in the application code.
And application-level isolation is exactly where IDOR vulnerabilities live.
The Numbers Tell a Story
Let's zoom out from our one fix to the industry data:
75% of organizations experienced a SaaS security incident in the last 12 months (AppOmni 2025 State of SaaS Security Report). Not a theoretical risk. Three out of four companies, right now.
63% of educational institutions using LMS platforms faced at least one security breach in 2022. Learning platforms are targets.
30% of breaches involved third-party partners (Verizon DBIR 2025). Your customer education platform IS a third-party system for your customers. Their data. Your infrastructure.
$4.44 million: average global cost of a data breach (IBM 2025 Cost of Data Breach Report). In the US, that jumps to $10.22 million.
70% of consumers say they would stop doing business with a company after a security incident. Customer churn increases up to 7% after a breach.
And here's the one that should keep multi-tenant SaaS builders up at night: recent PostgreSQL CVEs (CVE-2024-10976, CVE-2025-8713) showed that even database-level row security policies can fail. When optimizer statistics can leak sampled data from rows that RLS was supposed to hide, "the database handles isolation" isn't enough.
The Four-Line Fix That Represents a Systemic Problem
Our fix was four lines:
1. Get the current site from the request context
2. Get the quiz's site ID
3. Compare them
4. Return "not found" if they don't match
That's the entire pattern. It's the same pattern for every multi-tenant resource: before you render anything, verify it belongs to the requesting tenant.
The reason this vulnerability exists in the first place is simple: the code worked. A developer wrote a quiz shortcode processor that fetched a quiz by ID and rendered it. Functionally perfect. The quiz shows up, the user answers questions, the answers get saved.
No one checks for cross-tenant access when the feature works. The security review happens later — if it happens at all.
And that's the blind spot. Customer education features are often built by product teams focused on engagement, completion rates, and learning outcomes. Security review is an afterthought because the features feel low-risk. It's just a quiz. It's just a course. It's just an optin form.
But "just a quiz" contains your customer's proprietary assessment questions. "Just a course" reveals your customer's internal training strategy. "Just an optin form" captures leads that belong to one specific tenant.
What Should You Check?
If you run a multi-tenant customer education platform — or if you use one — here are the questions to ask:
1. Does every entity fetch include a tenant validation check? Not just "does it work" but "does it verify ownership." The quiz loads — but whose quiz is it loading?
2. Are shortcodes and embeds tenant-scoped? Anywhere a user can reference content by ID (quiz embeds, course links, resource attachments), that reference needs a tenant boundary check.
3. Is user-supplied data sanitized before interpolation? IDs, slugs, and parameters that end up in JavaScript, HTML, or SQL need to be treated as untrusted input — even internal IDs.
4. Do you have security tests for cross-tenant access? Not just "can tenant A access their own quiz" but "can tenant A access tenant B's quiz." Most test suites only test happy paths.
5. When was the last security review of your education features? Not the core product. The education features specifically — the quizzes, assessments, certificates, progress tracking.
The Uncomfortable Math
The Verizon DBIR 2025 reports that web applications take a median of 74.3 days to remediate after a vulnerability is identified. That's over two months of exposure.
Meanwhile, 88% of attacks against basic web applications involve stolen credentials, and brute force attacks against web apps nearly tripled in the last year.
The window between "vulnerability exists" and "vulnerability is fixed" is where breaches happen. And for customer education features — the kind that don't get priority in security sprints because they're "just training content" — that window stays open longer.
Our fix took four lines of code and about 20 minutes of analysis. The vulnerability had been there since the quiz shortcode was first implemented.
How long has yours been there?
The Question Isn't Whether. It's Whether Anyone Has Checked.
Your customer education platform stores quiz answers, learning progress, and employee completion data. If it runs on multi-tenant SaaS with shared infrastructure — and nearly all of them do — the question isn't whether tenant isolation is perfect.
The question is whether anyone has checked.
We checked today. We found something. We fixed it. That's how this works.
---
Sources: OWASP Top 10 2025, IBM Cost of Data Breach Report 2025, Verizon DBIR 2025, HackerOne Annual Report 2025, AppOmni State of SaaS Security 2025, CVE-2024-10976, CVE-2025-8713.