Every SaaS platform makes a choice at the architecture level: default-open or default-closed.
Default-open means new endpoints are publicly accessible unless someone remembers to lock them down. Default-closed means new endpoints require authentication unless someone explicitly makes them public.
One of these approaches fails silently. The other fails loudly.
Guess which one most platforms use.
The Number That Should Scare You
94% of applications tested showed some form of broken access control weakness.
That's not from a startup's blog post. That's from OWASP's 2025 Top 10, based on testing 2.8 million applications across dozens of cybersecurity firms. Broken Access Control has held the #1 position for two consecutive releases. Over 318,000 occurrences across 34 mapped weakness categories.
Security Misconfiguration — the cousin of default-open architectures — surged from #5 to #2.
These aren't obscure vulnerabilities. They're the most common security failures in software, and they share a root cause: platforms that trust developers to remember to lock every door, instead of locking every door and requiring developers to explicitly unlock the ones that should be open.
The SaaS Breach Trajectory
SaaS breaches increased 300% year-over-year between September 2023 and September 2024 (Obsidian Security 2025, based on 150+ incident responses). The fastest time from initial access to data exfiltration: 9 minutes.
Nine minutes.
That's not enough time to detect the breach, let alone respond to it. If your security depends on monitoring and response rather than prevention by default, you're playing a game you've already lost.
AppOmni's 2024 report (644 organizations across six countries) found that 31% of organizations experienced a SaaS data breach in the past 12 months — up 5 percentage points year-over-year. The primary causes? 41% stemmed from permission issues. 29% from misconfigurations.
Permissions and configurations. Not sophisticated zero-day exploits. Not state-sponsored attacks. Configuration mistakes.
The API Access Control Problem
99% of organizations experienced API security issues in the past 12 months (Salt Security Q1 2025, 206 respondents).
54% of observed attacks exploited security misconfigurations.
27% exploited broken object-level authorization.
28% resulted in an actual breach with sensitive data compromised.
Here's what broken object-level authorization looks like in practice: a user changes a number in a URL — from /api/course/42 to /api/course/43 — and sees someone else's data. That's an IDOR vulnerability. It's trivial to exploit. A curious user with a browser's developer tools can do it.
In a multi-tenant customer education platform, that URL change could expose one company's quiz responses, learning progress, employee completion records, or enrollment data to another company's administrators.
The Default-Open Architecture Pattern
Here's a common pattern in web application security configuration:
/api/** → permitAll()
That single line means: every API endpoint is publicly accessible by default. If a developer adds a new endpoint at /api/sensitive-data, it's immediately public. No authentication required. No authorization check. Nothing.
The developer has to remember to add security. And they won't always remember.
85% of SaaS users have more privileges than required for their roles (industry aggregate, 2024). 58% of organizations struggle to enforce access privileges. The over-permissioned account is the norm, not the exception.
The secure alternative:
Explicit whitelist: only /api/health, /api/public-key, /api/webhook → permitAll()
Everything else → requires authentication
Now if a developer adds /api/sensitive-data, it's locked by default. They'd have to explicitly add it to the public whitelist — a visible, reviewable action — to make it accessible.
One approach fails silently. The other fails loudly.
Why Customer Education Platforms Are Uniquely Exposed
Customer education platforms sit at an unusual intersection:
1. Multi-tenant by nature. Every customer's data lives on the same infrastructure. A single authorization check failure exposes one tenant's data to another.
2. Rich data targets. Quiz responses reveal what employees don't know. Learning progress reveals team capability gaps. Enrollment data reveals organizational priorities. Completion records affect compliance and certification.
3. Integrated into everything. Education platforms connect to SSO, CRMs, support systems, and HR platforms. A breach in the education platform is a breach in the ecosystem. ~2,300 weekly attacks target educational organizations and eLearning platforms.
4. Often built as afterthoughts. Education features get added to existing platforms without the same security scrutiny as the core product. The admin dashboard gets reviewed. The quiz API endpoint doesn't.
The result: platforms where the course content is public by design (that's the point — educate customers), but the administrative APIs, learner data, and cross-tenant boundaries use the same permissive defaults.
Defense-in-Depth: The Pattern That Catches What Defaults Miss
Default-closed is necessary but not sufficient.
Consider a course management API. The URL-level security says: only authenticated admins can access /admin/courses. Good. But what happens inside the controller?
If the code fetches a course by ID without checking whether that course belongs to the current tenant's site, URL security doesn't help. An authenticated admin on Site A can access Site B's courses by guessing or enumerating IDs.
That's where defense-in-depth matters:
Layer 1: URL-level security — only authenticated users with the right role can reach the endpoint.
Layer 2: Tenant validation — every entity fetch verifies it belongs to the current site.
Layer 3: Audit logging — every sensitive operation is recorded, so cross-tenant attempts are visible.
Any single layer can fail. Human error, code changes, edge cases. But all three failing simultaneously? That's orders of magnitude less likely.
Misconfigurations were the initial access vector in 30% of all cloud environment attacks in H1 2024 — nearly doubled from 17% in H2 2023. 82% of those misconfigurations were caused by human error, not software bugs.
Defense-in-depth exists because humans make mistakes. The question is whether one mistake opens the door or whether it merely triggers an alert.
The Multi-Tenant Isolation Reality
A healthcare SaaS platform discovered that modifying a URL parameter exposed any customer's patient records. The vulnerability existed for 11 months before discovery, affecting 127 enterprise customers across 23 states.
Eleven months. One URL parameter. 127 companies exposed.
PostgreSQL itself had a row-level security bypass (CVE-2024-10976) where security policies could be circumvented below subqueries. Even database-level tenant isolation isn't foolproof.
Average cost of a multitenancy-related breach: $4.5 million (IBM 2024).
The question for any multi-tenant SaaS platform — including every customer education platform — isn't whether tenant isolation is perfect. It's whether anyone has verified it.
What We Built
At Omumu, we recently audited every API endpoint in the codebase and found the default-open pattern: a catch-all rule that made any new /api/ endpoint publicly accessible by default.
The fix was straightforward:
• Replaced the broad catch-all with an explicit whitelist of 10 specific public endpoints
• Any unlisted API path now requires authentication by default
• Added defense-in-depth: course and tenant validation at the service layer, not just URL security
• Added audit logging for sensitive operations
• Wrote negative tests: "this endpoint MUST reject unauthenticated requests"
The whitelist approach means that the next developer who adds an endpoint doesn't need to remember to secure it. It's secure by default. Making it public requires a deliberate, reviewable action.
This is what platform-level security looks like versus hoping every developer remembers every time.
The $4.88 Million Math
Average global cost of a data breach: $4.88 million (IBM 2024). In the US: $10.22 million.
300% increase in SaaS breaches year-over-year.
94% of applications have broken access control.
41% of SaaS incidents stem from permission issues.
85% of users are over-privileged.
9 minutes from access to exfiltration.
And 82% of the misconfigurations that cause these breaches are human errors.
The security default gap is the distance between "we trust our developers to remember" and "the system enforces it regardless." It's the same pattern as the compliance gap (post #326): if security depends on the developer remembering, it will be missed.
Platform-level defaults beat developer-level discipline. Every time.
Three Questions for Your Next Security Review
1. When a developer adds a new API endpoint to your customer education platform, is it public by default or locked by default? If you don't know, it's public.
2. Does your platform validate tenant ownership at the service layer, or only at the URL layer? If a user changes an ID in a request, does the system check whether they're allowed to see that entity?
3. When was the last time someone tested cross-tenant access? Not "reviewed the code" — actually tested whether Site A can access Site B's data by modifying a request?
If you can't answer all three with confidence, the gap exists. And 94% of the time, it does.
Sources: OWASP Top 10:2025 (2.8M applications tested), Obsidian Security 2025 SaaS Threat Report (150+ incident responses), Salt Security Q1 2025 (n=206), AppOmni 2024 (n=644, 6 countries), IBM Cost of Data Breach 2024, SaaS Security Reports 2024-2025 (industry aggregate), CVE-2024-10976 (PostgreSQL RLS bypass).