A Working Login Can Still Expose Customer Data

A login screen can work perfectly while customer data is still exposed. Imagine a customer opening their invoice, changing the invoice identifier in the request, and receiving someone else's details. The application knows who they are, but it has not checked whether they are allowed to access that particular invoice.

Authentication establishes identity. Authorization decides what that identity can read or change. A customer portal needs both. A valid session alone does not establish permission to access every record.

OWASP describes broken object-level authorization as an API risk in which an endpoint accepts an object identifier without adequately checking the caller's permission to act on the requested object. In a business application, those objects might be invoices, orders, support tickets or project files.

The problem can affect more than reading data. An endpoint that updates or deletes records also needs to check whether the caller may perform that action on that record. Permission to view an invoice does not automatically imply permission to edit it.

See OWASP's explanation of broken object-level authorization for examples and prevention guidance.

Check authorization on the server for each requested record and operation. Derive the caller's identity from the verified session, then apply the relevant ownership, tenant membership or role rules before returning or changing data.

A button hidden in the interface is a usability choice, not an access-control boundary. The endpoint must enforce the rule even when a request arrives without using that interface.

Identifiers received from the browser are input, not evidence of permission. Using unpredictable identifiers can make guessing harder, but it does not replace an authorization check. A record identifier may still be disclosed through a shared link or another part of the application.

Test only applications you own or are explicitly authorized to assess. Use a test environment with synthetic data and two ordinary accounts, each with its own records.

• Confirm that each account can access its own records through the intended workflow.
• Verify that neither account can read or change records belonging to the other account by supplying the other record's identifier.
• Cover each relevant operation: viewing, editing, deleting and downloading attachments.
• Include different roles and tenant boundaries where the application supports them.
• Confirm that rejected requests leave the underlying data unchanged.

These checks should reflect the application's actual rules. A shared project may intentionally allow multiple users to view a record, while a private invoice may require a narrower scope. Record those expectations so a future change does not quietly broaden access.

Build permission checks into the delivery process alongside the visible customer experience. Review the endpoints that handle customer records, keep the rules understandable, and add regression coverage for the boundaries that matter.

No single check proves that an application is secure. But asking a specific question makes review more useful: what happens when a valid user requests something they do not own?

For dashboards, customer portals and connected workflows, that question belongs before release and whenever the access model changes.