Application access planning
A login proves who a user is. It does not decide which customers they may see, whether they can export a report, or whether they may approve a record created by someone else.
This guide shows how to turn vague access assumptions into an access matrix, test both allowed and denied actions, and use a tool such as PHPRunner to implement the resulting security model.
Quick answer: Start by listing the real users and tasks in an access matrix. For each task, define four things: the user or group, the application area, the records they may reach, and the actions they may perform. This turns a vague statement such as “Sales can access Customers” into rules that can be configured and tested.
The matrix forces vague roles to become specific business rules.
| User | Application area | Record scope | Allowed actions |
|---|---|---|---|
| Sales representative | Customers and orders | Assigned territory | View, add, and edit; no delete or bulk export |
| Sales manager | Customers, orders, and sales reports | Entire sales team | View, edit, approve discounts, and export |
| Customer | Self-service portal | Own company account | View invoices, submit requests, and update selected contact fields |
| Auditor | Reports and audit history | All relevant records | View and export; no data changes |
| Administrator | User and permission management | All accounts | Manage access; business-data changes only when specifically required |
Build the matrix from real tasks, not job titles alone. Two people called “manager” may need very different access, while an auditor may need broad visibility but no permission to change anything.
Start with no access and add only what each task requires. OWASP recommends least privilege, denying access by default, and validating permissions on every request. See the OWASP Authorization Cheat Sheet.
Each layer answers a different question and should be reviewed independently.
Authentication may use application accounts, a company directory, single sign-on, or another identity provider. Decide how accounts are created, disabled, recovered, and connected to employee or customer records.
Define which modules, tables, reports, dashboards, and administrative pages each group may open. Hiding a menu item improves navigation, but the underlying page must still reject an unauthorized request.
A salesperson may use the Customers page but see only an assigned territory. A customer may view invoices but only for their own account. This scope is often based on owner, company, department, location, team, or another relationship in the database.
View, add, edit, delete, import, export, print, and approve are separate permissions. A user who may view a record does not automatically need permission to download every record or change a protected status.
The exceptions often matter more than the obvious page permissions.
| Decision | Question to answer |
|---|---|
| Exports and printing | May a user download all visible records, only the current record, or no data at all? |
| Field-level sensitivity | May the user open the record but not see cost, salary, health, payment, or internal-note fields? |
| Shared and reassigned work | What happens when a record belongs to a team, an employee leaves, or responsibility changes? |
| Approval separation | May the person who created or edited a request also approve it? |
| Delete versus deactivate | Should users delete records, or mark them inactive while preserving history? |
| Custom buttons and APIs | Do background actions, direct URLs, integrations, and API calls enforce the same rules as normal pages? |
A permission model is incomplete until you test what each user must not be able to do.
| Test | Expected result |
|---|---|
| Open another user's record by changing its ID in the URL | The server denies access or returns no record. |
| Search, print, or export outside the allowed record scope | The same record filter applies to every output. |
| Call a custom button or API directly | The server repeats the authorization check instead of trusting the interface. |
| Submit a protected field that was hidden on the page | The server ignores or rejects the unauthorized change. |
| Remove a user from a group or disable the account | Access ends according to the application's session policy. |
| Create a new page, report, or integration | It starts with no access until permissions are explicitly assigned. |
Run these tests with representative employee, manager, customer, auditor, and administrator accounts. Repeat them whenever a new page, export, report, custom action, or API endpoint is added.
The access matrix maps to several built-in security features.
After connecting PHPRunner to your database, use its Security screen to configure authentication, groups, page permissions, and record-level access. Straightforward rules can be handled with built-in settings; business-specific exceptions can be enforced through the Security API and server-side events.
The important distinction remains the same: PHPRunner implements the model, while the access matrix defines what that model must allow and deny.
| Access layer | PHPRunner approach |
|---|---|
| Identity | Configure application accounts or supported external identity providers on the Security screen, with registration, password, and two-factor options where appropriate. |
| Application areas and actions | Use User group permissions to control access to tables, pages, and operations. Static permissions are maintained in the project; dynamic permissions can be administered in the generated application. |
| Record scope | Use Advanced security settings for owner-based rules such as allowing users to see or edit their own records. |
| Business-specific exceptions | Use the Security API and server-side events when permissions depend on assignments, departments, workflow state, or other rules that a standard group cannot express. |
| REST access | Apply authentication and the same record-level rules to API requests. See REST API security. |
Prove one complete permission rule before configuring the whole application.
Choose one important data area and two contrasting users. For example, configure a sales representative who can edit assigned customers and a manager who can view the team and approve discounts. Test both the allowed workflow and every relevant denial case.
Once that rule works consistently on normal pages, direct URLs, searches, exports, custom actions, and APIs, use the same matrix to add the remaining roles. This creates a security model that can be explained in business language and verified after the application changes.