App permissions determine which information a customer can view or change. A successful sign-in does not prove that those boundaries are correct.
A customer can sign in, edit their profile and use your app. Everything looks ready. But what happens if that same customer can also change the number that says how much of their allowance they have used?
In our conversation with Candace, we discussed a usage-limit example that exposed this gap. The visible journey worked, while the rules behind it gave the user more control than the business intended. A successful demo would be unlikely to reveal that problem.
Start an app permissions review with field ownership
A display name belongs in a customer’s profile settings. Their subscription status, account role and remaining credits usually need a different owner: your application or an authorised member of your team.
Storing those values in one database table is not automatically unsafe. The important question is which fields a user can read or change, and how those rules are enforced. Ask your developer to show the allowed fields for a profile update. An update should accept only the changes that account is entitled to make.
OWASP’s mass assignment guidance explains why explicitly allowing editable fields matters. A convenient update mechanism should not accidentally expose business-controlled values.
Signing in does not grant every permission
Knowing who a user is and deciding what that user can do are separate checks. A customer may be allowed to view their own invoice without being allowed to see another customer’s invoice. A team member might read a report without being able to change billing settings.
The server needs to enforce those boundaries when it receives a request. Hiding an admin button in the interface does not establish that boundary. OWASP recommends checking permissions on every request in its authorization guidance.
Review the actions that could change your business
Use a test environment and accounts with different roles. Ask the developer to demonstrate both permitted actions and actions that must be refused. A useful review starts with a simple list:
- Which account can view, edit or delete each type of record?
- Can a customer change credits, prices, subscription status or their own role?
- Are records restricted to the correct customer or organisation?
- What happens when a session expires or an account is suspended?
- Which sensitive changes are recorded so the team can investigate a mistake?
Keep the evidence alongside your release checklist. “We tested it” is much less useful than knowing which account attempted which action and what the system did.
Make permissions part of the product brief
Access rules should be discussed when the product is scoped. Adding a manager role, shared workspace or billing feature changes those rules, even if the interface changes only slightly.
If your team is preparing a product for launch, our web platform work can help connect the customer journey with the business rules behind it. Bring the actions each role needs to perform, along with the actions each role must be prevented from taking.
