Security and Privacy
Check authorization on every business object
An authenticated customer should not automatically see every invoice or attachment. Define access at the business object level, then ask for evidence across screens, exports, and background work before accepting the feature.
A customer portal can look correct while its access rules remain incomplete. The useful question is not just whether someone can sign in. It is whether this person can perform this action on this particular invoice, order, or document. Make that question part of acceptance criteria before development begins.
Separate identity from permission
Authentication verifies identity. Authorization determines whether a requested action is allowed. OWASP treats these as distinct decisions and recommends permission validation on every request.[1] A successful login therefore does not establish permission to read every record.
Start with a compact table of actors, objects, and actions. Include customer contacts, delegates, finance staff, and service accounts. Distinguish reading an invoice from changing its payment destination. Record ownership, organization membership, and any approved sharing relationship as separate conditions.
Put the decision beside the data
OWASP advises server-side access checks and warns against reliance on client-side controls.[1] Ask the team to show where the server decides access before it returns data or accepts a change. Include attachments, search results, totals, and downloadable exports in that review.
Recommend one consistent policy interface rather than scattered role checks. This need not mean one expensive remote call for every row. The design can constrain data queries and validate actions together. Performance improvements must preserve the same access decision, including when permissions change.
Hypothetical example: a disputed invoice
In a hypothetical distributor portal, a purchasing contact can view invoices for one branch. A regional manager can view several branches but cannot edit bank details. The product owner writes these as separate permissions, rather than granting both users a broad customer role.
A test then covers an invoice attachment, a consolidated export, and a dispute submitted after branch access is removed. The expected refusal includes no invoice details. This example illustrates acceptance evidence, not a claim that any deployed portal is secure.
Evidence to request before sign-off
Use synthetic records and approved test accounts. Require both allowed and denied outcomes, with an explanation of the business rule behind each result.
- List the ownership or sharing condition for each object and action.
- Test unauthorized reads and changes through every supported interface.
- Check exports and attachments against the same object permissions.
- Repeat tests after membership removal and delegated access expiry.
Accept the maintenance cost
Fine-grained rules create more policy decisions and test cases than a single administrator flag. Keep a named business owner for exceptions. Revisit the table when the workflow changes, not only when a new screen appears. Accept a feature only when its access evidence covers the underlying objects, not merely its visible navigation.
