Hiding a button doesn’t necessarily prevent someone from performing the action. We check what users and administrators can actually do by following requests to the code that reads or changes data.
Check permissions
We start with the rules: who may view, change or delete each resource? We test different accounts and roles, including attempts to access another organisation’s data, and check enforcement in the APIs.
- Authentication, sessions and role changes
- Tenant isolation and resource ownership
- Administrative actions, exports and uploads
Examine credentials and integrations
We check where credentials are used, database permissions and calls to external services. For payments, we review event verification and how purchases or subscriptions are updated. Applicable OWASP guidance can inform the checks; this is not a security certification.
Explain the findings
We describe each issue and its possible effect on the product, distinguishing verified problems from questions needing more tests. You get the affected components and the fixes we recommend making first.
Fix and test again
If we agree on implementation, we test both the operations that should be blocked and the ones that should still work. If a fix changes a product rule, we agree on the intended behaviour first.