Why We Never Load Every User Into a Dropdown
Some of the most important security decisions in our platform happen in the least glamorous places. One of them is the humble dropdown that lets an administrator pick a person: an author for a blog post, an agent for a support ticket, a host for an event.
In many applications, filling that dropdown is a one-line job: list all the users. In VoVo, our multi-customer platform, that one line would be a data leak. Here is why, and what we do instead.
Why people are different from other data
Most records in our platform belong to exactly one customer account. A blog post belongs to one account. An order belongs to one account. Those records carry the account's identifier, and our data layer automatically filters them so each account only sees its own.
People are different. One person can be a member of more than one account. A consultant might help two organizations. A pastor might run a church site and a personal coaching site. So a person's login record does not belong to a single account. The link between a person and an account lives in a separate membership table.
That design is correct, but it means the automatic filter that protects posts and orders does not apply to people. A query for "all users" really does return everyone on the platform.
The pattern we use
Whenever a screen needs a list of people, we build it from the memberships of the current account, not from the user table directly. In plain terms: start with the account, find who belongs to it, and only then look up their names.
The same rule applies everywhere people appear:
- Form dropdowns for choosing an author, owner, assignee or host
- Table filters that narrow a list by person
- Search boxes that look up a member by name or email
- Profile pages that show one person's details
- Notifications that go to administrators or role holders
- API endpoints that return people
Why frameworks make this easy to get wrong
Modern admin frameworks offer convenient shortcuts that load related records automatically. They are great for data that is already filtered by account. For people, the shortcut can quietly bypass the account boundary, because the related table is not account-scoped.
Our engineering standards name this pattern explicitly and tell every developer and every AI assistant to avoid it. Instead, each screen uses a small helper that returns only the current account's members. It is a few extra lines, and it removes a whole category of risk.
Notifications follow the same rule
The same mistake can hide in places that do not look like lists at all. When a new support ticket arrives, the system needs to notify the account's administrators. When a payment fails, it needs to tell the account owner. If the code finds "administrators" by role alone, without starting from the account's memberships, it can notify administrators of other accounts, and now a stranger has received a customer's ticket subject or payment details in their inbox.
So notifications, alerts and email recipients are built the same way as dropdowns: start from the account, find its members, then filter by role. It is the same small helper idea, applied wherever a person is chosen by the system rather than by a human clicking a menu.
Testing the boundary
A boundary is only real if it is checked. When we review a feature that lists or searches people, we look specifically at where the names come from. During browser checks we sign in to one account and confirm that names from another account never appear, even when we type a name we know exists elsewhere.
The bigger lesson
This is one example of tenant-first thinking: before writing a query, ask whose data it touches. The places where data is shared across accounts, like people, are exactly the places where the usual protections may not apply, so they deserve the most care.
If you run an organization on VoVo, this is part of why your member list stays yours. You can learn more about the platform on the VoVo page.
Frequently asked questions
Why can one person belong to several accounts?
People often help more than one organization, such as a consultant, a volunteer or an owner with two businesses. Separate memberships let one login access several accounts without merging their data.
What is the risk of listing all users?
In a shared platform, listing all users can expose names and email addresses from other customers' accounts, which is a privacy breach even if nothing else is shown.
How do you prevent a search from finding people in other accounts?
Searches start from the current account's memberships and only then match names or emails, so a person who is not a member of that account is never returned.
Related Posts
Every AI Call Is Registered Before It Runs
AI features cost money and touch customer data, so we keep a registry of every one. Here is how a call that is not on the list is refused before anything is spent.
Why Card Numbers Never Touch Our Servers
The safest way to protect card numbers is to never hold them. Here is how our checkout forms send card details straight to the payment processor instead.
Letting Customers Get Paid Directly With Connected Accounts
When an organization sells through our platform, the money should land in its own account. Here is how connected accounts, platform fees, refunds and disputes work.
Background Jobs That Remember Whose Work They Are Doing
Slow work like sending email or resizing images happens in the background, long after the request ends. Here is how our jobs carry the right customer with them.
Unique Per Customer, Not Unique Everywhere: Composite Keys
Two organizations can both have a page called About. Here is how composite unique keys keep addresses unique inside each account without blocking other customers.
Comments (0)
No comments yet. Be the first to share your thoughts!