Portal permissions: each customer sees permitted records

Signing in does not authorize every record

A customer portal should check who is accessing it, their company and location, the requested document and permitted action. Hiding a menu section does not establish file protection. The same rule must hold for search, direct links, downloads, exports and changes.

OWASP recommends granting only needed privileges, denying by default and checking authorization on every request. Microsoft warns for Power Pages that hidden pages are not secured and direct downloads should be tested with unauthorized and signed-out users. These are those sources' recommendations and conditions; demonstrate your own boundaries.

Example: a North link reaches Green

BN opens DOC-41 successfully. Copy its link and try as G: expect denial without file, amount or other private details. BC should also be denied despite belonging to Blue because the test scope is Central. Signing in identifies a person; it does not automatically expand permitted locations.

G searches for DOC-41's number, exports permitted documents and opens a detail view. No path should reveal Blue. Staff examine content, totals and files, not just a hidden button. If special sharing links exist, define issuer, allowed actions, expiry and withdrawal; each exception needs its own test.

North's purchasing contact sees orders but not DOC-41 under the matrix. Switching to the authorized administrative profile requires approval and scope reevaluation. A received URL must not expand access. Repeating the same assignment should preserve the same permission rather than enable every location.

Test revocation from an open session

In another variant, BN loses access while a session is open. The next request and new download should be denied under the defined rule; another sign-in must not restore permission. Preserve revocation approver and time. Check outcomes after the change as well as administration-screen text.

Do not treat an already downloaded copy as disappearing when future access is revoked. Define handling and retention with responsible staff. Keeping permission history does not mean keeping a user enabled. If access was revoked by mistake, restoration needs approval and a new scope test.

Require allowed and denied cases

• Create two fictional customers and two locations within one. Establish allowed access before comparing denied cases.
• Test the same document from another company, location, unprivileged profile and signed-out person.
• Use search, direct links, downloads and exports. Check private data in totals and error messages too.
• Remove permission with the session open. Test an approved expansion and its repetition.
• Record test user, action, expected outcome, observed outcome and evaluated version without passwords or production documents.

These ten tests do not certify complete security. They examine concrete boundaries before invitations and after material changes. If another customer's data appears, record the case and correct the boundary before widening access; hiding information after delivering the file is insufficient. Technical staff should expand testing to actual scope.

Prepare profiles, customers, locations, documents and actions. Decide access and revocation authority, sharing exceptions and private data. For general scope, review the customer portal guide; for commercial controls, B2B customer prices. A custom portal consultation can examine the matrix before defining screens.