What should a customer portal export be allowed to contain?
An export button can turn a narrow account view into a file containing far more information than the user needs. Before adding it, ask which records the person may obtain, when that permission is checked and what happens if access changes while the file is being prepared.
These questions are useful for Australian trade suppliers, multi-site customers and other organisations where several people use related accounts. They concern the actual business relationship, not simply whether someone has successfully signed in.
Describe the export as a permission decision
Imagine a fictional supplier portal with two trade accounts. User Erin is allowed to view orders for Account North. User Sam is allowed to view Account West. The proposed export contains the selected account’s order references, dates, approved status and delivery-site labels for a chosen period.
The business does not approve exporting internal credit notes, private staff comments or another account’s orders. Those fields should not enter the export merely because they exist in the same database table.
Write the requirement in terms the account manager can review: “Erin can export the permitted order fields for Account North while her access to that account is active.” This is more useful than “logged-in users can download reports”.
Check the generated file, not just the visible page
In a flawed prototype, the account page correctly shows North’s orders, but the background export job selects every order in the date range. The screen appears private while the downloaded file includes West’s records.
A private acceptance exercise should use a small known set. Give North two demonstration orders, N-101 and N-102, and West one order, W-201. Erin’s export must contain exactly the two North records and the approved fields. Sam’s export must contain W-201 and must not acquire North’s records because both users choose the same dates.
A record count alone is insufficient. An export with two rows could still contain the wrong two rows. Inspect the identities, account relationship and fields as well as the total.
Consider permission changes during preparation
Suppose Erin requests a larger export and the job waits in a queue. Before it is prepared, her access to Account North is removed. The approved policy for this fictional portal is that she must retain current access when the export is generated and when it is downloaded.
The review therefore needs two checks. A queued job must not produce a new downloadable file for her after that removal. If a file was prepared while she still had access but has not yet been obtained, a later download request must follow the current permission decision.
The implementation depends on the chosen application and storage arrangement. A public static file URL that continues to work for anyone who has it would not satisfy this policy. Nor would hiding the export button while leaving the download endpoint open.
OWASP’s authorisation guidance distinguishes identity from permission and addresses checks on requested resources. Use that guidance to review the actual export and file-delivery design, rather than treating a login screen as the security boundary.
Define the limits honestly
Removing access cannot recall a file already downloaded to someone’s device. The organisation needs an appropriate policy for the information it permits people to export and the responsibilities attached to it. A developer should not promise remote deletion of copies the application no longer controls.
The system can still limit the fields it releases, protect stored export files, expire access according to the agreed arrangement and record enough information to investigate an authorised export. Logs themselves should avoid becoming another unnecessary copy of private data.
Ask who may request an export on another person’s behalf and who can approve a wider account relationship. A support employee should not bypass the normal scope simply because a customer emails a request for “everything”.
Make the review include an unaffected account
After Erin’s removal, Sam should still be able to obtain the approved West export. This checks that access removal is applied to the intended relationship rather than disabling all exports or deleting shared records.
The final demonstration should cover the normal request, the incorrect-account attempt, a queued job affected by removal and an existing file whose download is no longer permitted. The reviewer should see the resulting file or refusal, not only an explanation that a permission setting was changed.
Faith Forge Labs can scope these decisions as part of customer portal development. Raise the export requirement early: it affects data selection, background work, storage and account support, even when the visible feature is only one button.