Access Control Gaps in Custom Business Platforms

TLDR: Most custom platforms get authentication right and skip authorization entirely. The result is a system where a logged-in user can read, modify, or download records that belong to someone else. This is the most common class of vulnerability we find in custom business software, and it is preventable before a single line ships.

Authentication Is Not Authorization

Every developer adds a login screen. Far fewer add the check that comes after: does this specific user have permission to access this specific record?

Authentication answers "who are you." Authorization answers "what are you allowed to do." Custom software almost always implements the first and treats the second as implied. That assumption is where data exposure happens.

How One Endpoint Exposes the Whole Dataset

In a recent security audit on a custom business platform, unrelated to the guatemaladigital.com assessment, we found this pattern intact across multiple endpoints:

1. The application uses sequential numeric IDs for records — order 1001, order 1002, order 1003.
2. An endpoint exists to retrieve a record: GET /api/orders/1001
3. The endpoint checks that the user is authenticated. It does not check that the user owns order 1001.
4. Any authenticated user can increment the ID and retrieve every record in the system.

No exploit required. No special tooling. A logged-in account and a for loop.

This class of vulnerability is called Broken Object Level Authorization (BOLA). It sits at the top of the OWASP API Security Top 10 because it is the most common critical finding in API security audits. Standard QA never catches it — QA tests that features work, not that access boundaries hold.

Why It Appears in Well-Built Software

Authorization is not a framework-level setting. It is a decision made endpoint by endpoint, feature by feature: who owns this record, which roles can access it, what happens when the check fails. Under deadline pressure, those decisions get made implicitly or skipped. The platform passes QA, handles real traffic, and leaks its full dataset to anyone who knows the URL structure.

We documented a real-world outcome of this failure class in our guatemaladigital.com assessment. Different entry point, same root assumption: authentication was enough.

Off-the-Shelf Platforms Handle This Differently

WordPress, Odoo, and Shopify implement object-level authorization at the framework level, the product of years of production exposure and forced fixes. Custom software starts from zero, with every endpoint a decision point and no framework enforcing that the decision gets made. That structural difference is why a targeted security audit matters on any custom build before it reaches production users.

Companies that manage this internally carry the full risk of every missed check. A specialist partner carries it with you, and brings the review practice that finds these gaps before they cost anything.

The Questions to Ask Before Sign-Off

If you are evaluating a vendor or reviewing a system in production, these are the questions that surface this risk:

• How are list and detail API endpoints scoped to the requesting user?
• What happens if a logged-in user requests a record ID that belongs to a different account?
• Is object-level authorization tested as part of QA, or only authentication?
• Who reviews the authorization layer on new endpoints before they ship?

If the answer to the last question is "the developer who wrote it," that is not a review.

How We Build It

At nimble., every API endpoint enforces object-level ownership at the service layer. The check is "does the authenticated user's account own this specific record," and it runs before any data is returned, on every endpoint, including list views. It is a concrete outcome of building on a framework with a strict service layer rather than writing queries with no ownership model attached.

A targeted authorization audit on your existing platform will surface whether this gap exists. Get in touch if you want a scoped review.