Your app has a login. Can users still access someone else's data?

I reviewed a founder's product and could see personal information, including home addresses, within about ten minutes. I wasn't using sophisticated tools. The problem was visible through a few ordinary interactions with the app.

The founder had built something useful. The missing piece was a boundary around what each user was allowed to see.

If you have recently launched a product, especially one you built yourself with AI, it is worth asking someone to check that boundary before you bring more customers into it.

What happens after someone logs in?

A login establishes who someone is. Your product still needs rules about which records that person can access and which actions they can perform. Those are separate decisions.

Imagine a booking platform with two business customers. Each has its own staff, bookings and invoices. Everyone can sign in successfully, and the dashboard shows the right company name. That still leaves a question: does the system reject a request from one company for the other company's invoice?

The protection needs to exist where the request is handled. Hiding a button or removing a link from a page does not, by itself, stop the underlying action. OWASP recommends checking permissions on every request and denying access unless it is explicitly allowed.

Write down the rules before checking the code

You can contribute to a permissions review without reading a line of software. Start with the people who use your product and the information they need.

For the booking platform, a receptionist might need to edit appointments, while an accountant needs invoices. A business owner might invite colleagues. A customer who has left the business should lose access. These rules depend on how the business operates, so the developer needs your input.

Put the rules in a simple table: the type of user, the information they may access and the actions they may take. Include the exceptions. Can a support worker view a customer's account? Can a manager export everything? Who can change someone else's role?

If the answer is currently “I think the tool handles that”, you have found something to investigate.

Ask for evidence using separate test accounts

A useful demonstration uses accounts with different permissions and records containing fake data, in an environment you control. Ask your developer to show both an allowed action and a rejected one.

You should be able to see that an ordinary user cannot perform a manager's action, and that one customer cannot retrieve another customer's records. Include downloads and exports in the conversation, since the dashboard is only one way information leaves a product.

Ask what happens when access changes, too. For example, if a staff member leaves, when should an open session stop working? That is a product rule to agree and verify, rather than leave implicit.

This exercise gives a review a clear starting point. A broader security assessment may uncover other issues, but “can people cross these boundaries?” is already a concrete question.

Turn the finding into a decision

If a review finds an access gap, ask which users and information are affected, how to contain it, and what change will prevent it recurring. The explanation should help you decide what can safely stay available while the issue is addressed.

Avoid treating a successful fix to one screen as proof that every route into the same data is protected. Ask how the rule has been checked elsewhere and how future changes will be tested against it.

At JiNi, we help identify data exposure risks and fix security gaps in existing products. If you are unsure who can access what in your app, contact us about a permissions review. Tell us what your product does, the kinds of users it has and the data you need to protect, so we can discuss where to begin.