One signed-in account can still lack permission
Imagine a company selling training material to customers in Egypt. A visitor signs in successfully. That tells the application there is a valid session for an account. It does not answer whether the customer purchased a particular course, whether a refund changed their access or whether they can edit the course price.
The business needs separate decisions for each action. A customer may update their own display preferences, a content editor may change lesson text and a finance employee may review payment records. None of these permissions follows automatically from being logged in.
OWASP's authorization guidance distinguishes these responsibilities and recommends minimum necessary permissions with checks on each request.
Where hosted authentication contributes
Gammal Tech provides hosted login and application user-data storage. This can reduce the login infrastructure that a website team builds and operates. The application receives a session credential rather than the underlying account's email, phone number or identity documents.
The business must still decide what its application permits. A verified account is not proof of employment, managerial authority, a subscription or ownership of an order. Those are separate business facts with their own evidence.
Keep the design focused on the action being requested: who is asking, which record they want to affect, what operation they want to perform and which trusted information supports that permission.
Write an access matrix before writing conditions
| Action | Who may perform it? | Trusted evidence needed |
|---|---|---|
| Change a display preference | The user who owns that preference | Valid session and correct user scope |
| Open paid course content | A customer entitled to that course | Verified entitlement for the requested course |
| Edit a lesson | An assigned content editor | Current editor permission for that content |
| Issue a refund | An authorized finance operator | Current permission plus the relevant transaction |
Write a separate row when the risk changes. Reading an invoice and changing its bank details should not share an unexplained blanket permission. Name the owner who approves each rule and what event ends that access.
User-editable data is not permission evidence
Suppose a profile object contains theme, language and paid. The first two describe a customer's preferences. If the same customer can modify paid, that field cannot prove a purchase. Saving the object on someone else's server does not make a customer-supplied claim authoritative.
Use an explicit separation between settings that users may change and decisions only a trusted business process can establish. Check payment through the documented trusted verification process before fulfillment. Keep administrative rights outside user-editable settings.
This is also relevant to imported spreadsheets and support actions. A convenience tool that copies every profile field into an access record can silently turn editable information into authority. Review where each important field originated and who can change it.
A hidden button is not an access boundary
Hiding an administrator button helps make the interface clear, but the protected operation must independently reject unauthorized requests. A customer can alter browser state or make a request without using the visible button. The decision must happen in a trusted backend or service capable of enforcing the rule.
For a static frontend, choose services that can enforce the required actions. If the available service cannot represent the permission you need, redesign the workflow or add an appropriate trusted component. Do not invent an undocumented endpoint or rely on JavaScript alone.
Domain registration and session checks have useful roles, but neither answers every business question about access. A request from the right website and a signed-in person can still ask for an action that person should not perform.
Test the refusals as well as the happy path
- Try the action while signed out and record the expected refusal.
- Repeat it as an ordinary user when elevated access is required.
- Request another customer's record using a test environment and invented data.
- Change user-editable fields and confirm that no paid or administrative right appears.
- Remove a test user's business permission and confirm the protected service rejects subsequent unauthorized actions.
- Verify that a failed authorization check does not reveal sensitive record details.
Keep the matrix with the application documentation. Review it whenever a new role, resource or paid feature is introduced. The result is a system whose permissions can be explained to the business owner, implemented by developers and checked without guessing what a successful login was supposed to mean.
Common questions
Does a verified identity automatically deserve administrator access?
No. Identity verification and administrator authorization answer different questions. The business must explicitly assign and enforce the relevant administrative permission.
Can I use a field in user-editable JSON to prove payment?
No. A user-changeable value cannot independently prove payment or entitlement. Use a trusted verification and fulfillment decision outside that editable data.