Hiding a button is not access control: write a permission rule you can test
A feature request says, “Only reviewers can open customer requests.” The designer hides the button for everyone else. The feature looks finished, but the team still needs to agree which reviewers can read which requests, and how the application enforces that decision.
Access control is how a system allows or refuses an operation on something it protects. Authentication checks identity, such as during sign-in. Authorisation decides whether that identity may perform a particular action. Signing in does not settle every permission question.
freeCodeCamp’s 15 October 2026 security-by-design guide prompted this practical exercise: take one feature and write a rule that developers and testers can check. You can contribute to the conversation from product, delivery or development, without starting with a particular security library.
Start with a decision about one action
“Reviewer” is a role, or named set of responsibilities. It may be only part of the decision. A reviewer assigned to one project might have no reason to read another project’s customer requests. Reading, editing and exporting are also different actions.
OWASP’s authorisation guidance recommends granting only the access needed, refusing access when no rule permits it, and checking permissions on each request. It also warns against relying on browser-side controls. Hiding a button can guide someone through the interface, but the service handling the operation must enforce the rule.
A fictional example: a shared request tracker
Illustrative example: a fictional company uses a tracker with two projects, Orchard and Birch. Leena and Owen both have the Reviewer role. Leena currently belongs to Orchard; Owen belongs to Birch. Each customer request belongs to one project.
Proposed policy for this example
A signed-in Reviewer may read a customer request only while they are a current member of the project that owns it. This rule grants no editing or export permission. Other requests for access are refused unless another explicitly approved rule allows them.
The fictional product owner agrees that removing project membership must affect the next read request. That is a requirement for the team to implement and verify, not an assumption about how a framework behaves. Information already read or downloaded raises a separate question about retained copies.
Turn the policy into a useful work item
1. Name the person, action and record
Purpose: Make the decision specific enough to discuss.
Replace “authorised users can access data” with a concrete operation: Leena reads one Orchard customer request. Record the relevant relationship between the person and the record. Here, that relationship is current membership of the owning project.
Ask a colleague to describe the same rule using Owen. If “he is also a reviewer” is enough to grant access, the project boundary has disappeared. Resolve that disagreement before treating the requirement as complete.
2. Agree the refusal outcome
Purpose: Describe what must stay protected.
For this example, a refused read must return no customer-request content and must leave the record unchanged. The interface should explain that access is unavailable and offer an appropriate support route, without displaying the protected request in the explanation.
Agree the detailed response with the team. Do not prescribe one error message or technical status code for every product. Record the user-facing behaviour and the evidence a tester needs to check it.
3. Find the enforcement point
Purpose: Connect the written rule to the operation.
Ask the developer where the permission decision happens before protected content is returned. Include alternative routes to the same operation, such as a saved link or a mobile client. An application programming interface, or API, is a route through which software requests work or data from another system.
For the fictional tracker, the page and its API must respect the same reading policy. Ask how changed membership reaches the permission check, including any cached permission information. Record unanswered implementation questions beside the requirement.
Check the boundary, not just the happy path
OWASP’s testing guidance uses permission matrices to make expected access decisions explicit. The small comparison below applies that idea to the fictional tracker. These are proposed expectations, not results from a real system.
| Proposed request | Expected result |
|---|---|
| Leena, current Orchard member, reads an Orchard request. | Allow the read. Return only the content covered by the agreed policy. |
| Owen, Birch member with the same Reviewer role, reads an Orchard request. | Refuse. Return no protected request content. |
| Leena reads again after her Orchard membership is removed. | Refuse the next read request, as required by this fictional policy. |
| Leena, current Orchard member, asks to export project requests. | Refuse. Reading permission does not grant export permission. |
| Someone who is not signed in asks to read an Orchard request. | Refuse under this policy. No anonymous read permission was agreed. |
Use test accounts and invented records in an environment your team has approved for testing. Check the service response as well as the visible page. A missing button or an error banner is insufficient evidence if protected content is still returned behind it.
Keep expected and observed results separate. Beside each case, record the account, record, relevant membership state, date, observed outcome and evidence location. Mark an unperformed test as untested. These five cases are a starting set; they do not establish security across the whole application.
Keep a permission note beside the feature
- Operation: What exact action is being requested on which kind of record?
- Allow condition: Which identity, role and relationship permit it?
- Refusal: What must be withheld or left unchanged?
- Change: What happens when a relevant role or relationship ends, and when?
- Evidence and owner: Which allowed and refused cases will be checked, and who resolves unclear rules?
Try this with one work item today. Write the allowed case, then change only the project, membership or action. If the team disagrees about the outcome, keep that decision open and name its owner. The useful result is a clear permission rule with observable checks that the people building the feature understand.
This recent-discussion-inspired evergreen exercise uses established access-control principles. The tracker, people, policy, comparison cases and five-part permission note were composed for Coded Female. The example is not a complete security design or evidence that any real application is secure.
You May Also Like
Mastering Agile Project Management with Scrum: A Comprehensive Guide
Removing blockers: a practical guide for Scrum Masters
