Your API Works. But Can One Customer Access Another Customer’s Data? Why Mass Assignment and BOLA deserve more attention in API security
If you run a SaaS platform or any application where several customers use the same system, there’s a question your security team should be able to answer confidently:
Can one customer access, change or retrieve something that belongs to another customer?
Your users may be logging in correctly. Your traffic may be encrypted. Your firewalls may be properly configured.
And you could still have an API security problem.
Two vulnerabilities that can create this kind of exposure are Broken Object Level Authorization (BOLA) and Mass Assignment.
They work differently, but both can cause problems when an API doesn’t properly control what a user is allowed to access or change.
So, what exactly is BOLA?
Let’s take a simple example.
Imagine your application has an API endpoint like:
GET /api/customers/12345/orders/789
The application knows who is making the request. Good.
But that’s only authentication.
The next question is more important:
Is this particular user actually allowed to see order 789?
If the API checks only that the person is logged in, rather than checking whether the order belongs to that user’s account or organisation, an attacker may be able to manipulate the object identifier and access information they shouldn’t see.
That’s BOLA.
And this is where an API vulnerability becomes a business problem.
What could be exposed?
Depending on the application, an authorization failure could expose things such as: • Customer records
• Orders and invoices
• Internal documents
• Financial information
• Support tickets
• Business reports
• User information
• Other customer-specific resources
Your customer is not going to care that the vulnerability is called BOLA. Their question will be much simpler:
“Why could another customer see our data?”
That’s the problem you need to prevent.
What about Mass Assignment?
Mass Assignment is a different type of problem.
It can happen when an application accepts fields from an API request and automatically maps them to an internal object without properly restricting which fields the user is allowed to change.
Consider a normal user profile.
Perhaps the user should be able to change:
• Name
• Phone number
• Company address
But what happens if the backend also accepts fields such as:
• role
• account status
• tenant_id
• is_admin
Those aren’t ordinary profile settings. They can affect permissions, account ownership or access to other parts of the system.
If the application doesn’t properly control those fields, a user could potentially attempt to change something they were never supposed to control.
The problem isn’t simply that the API accepts additional information.
The problem is that the server may be trusting the client with decisions that should belong to the application.
Why does this matter so much in a multi-tenant application?
Think about a SaaS platform with two customers:
Tenant A → API → Application → Database
Tenant B → API → Application → Database
From the customers’ perspective, those two environments should be separated. Customer A should not be able to retrieve Customer B’s invoices.
Customer B shouldn’t be able to modify Customer A’s users.
And neither customer should be able to change information that belongs to another tenant.
The database can be configured correctly. Your network can be secure. Your data can be encrypted.
The application can still make the wrong authorization decision.
That’s why API security isn’t just about asking whether an endpoint is protected. You also need to ask:
“What is this particular user allowed to do once they’re inside?”
And GraphQL?
The same principle applies to GraphQL.
GraphQL gives applications a lot of flexibility because clients can request the objects and fields they need instead of relying on a fixed set of REST endpoints.
That’s useful.
It also means authorization needs to be handled carefully.
It’s not enough for a GraphQL API to ask:
“Is this user logged in?”
It also needs to determine:
“Is this user allowed to access this object and these particular fields?”
That becomes very important when the same GraphQL API serves multiple customers.
A user belonging to Tenant A shouldn’t be able to use a perfectly valid query to retrieve information belonging to Tenant B.
Don’t Ask “Is Our API Secure?”
That’s a very broad question.
A better question is:
“Can a user from Tenant A access or modify something belonging to Tenant B?” Then test it.
Your testing should cover more than just the login process. Look at:
• REST endpoints
• GraphQL queries
• GraphQL mutations
• Different user roles
• Tenant boundaries
• Object identifiers
• Nested resources
• Administrative functions
• Sensitive fields
The goal isn’t simply to find out whether someone can reach the API.
It’s to establish whether the API consistently enforces who can access what.
Because you don’t need a complete compromise of your platform for an authorization weakness to become a serious incident.
Sometimes one missing check is enough.
What can you do about it?
There is not a single setting you can turn on to eliminate BOLA or Mass Assignment. Your development and security teams should start with a few basic principles. 1. Keep authorization on the server
Don’t rely on the application or client to tell the server whether someone should have access to an object.
The server needs to make that decision.
2. Check tenant ownership
When a user requests a sensitive resource, verify that the resource actually belongs to the user’s tenant and that their role permits the requested action.
3. Control which fields users can change
Don’t automatically allow every field received from an API request to be written to an internal object. Define what each type of user is actually allowed to modify.
4. Test authorization separately from authentication
A successful login only tells you who someone is. It doesn’t tell you what they’re allowed to access.
5. Test REST and GraphQL
Don’t assume that controls working correctly in one API architecture automatically protect another. Test the actual authorization paths exposed by each API.
6. Test again after fixing the problem
A developer saying the vulnerability has been fixed is not the same as proving that it has been fixed.
Retesting should confirm that the unauthorized access path is actually closed. The Question Behind All of This
For a security engineer, BOLA might appear as another finding in a vulnerability report. For a CEO or CTO, the question is much easier to understand:
Can one of our customers see another customer’s information?
If there is any uncertainty around that answer, it’s worth investigating.
API security isn’t only about protecting endpoints.
It’s about protecting the boundaries between your customers, your data and your business. Is Your API Enforcing Those Boundaries?
At Cyenetic Security, we assess APIs for authorization weaknesses, insecure object access and other vulnerabilities that could expose sensitive customer or business information.
If you operate a multi-tenant SaaS platform, REST API or GraphQL application, we can help you assess whether your authorization controls are working the way you expect them to.
Don’t wait for a customer to discover the problem first.
Talk to Cyenetic Security about an API Security Assessment
Cyenetic Security
Find the weakness. Fix the risk. Protect what matters.