IDOR is a missing permission check on a referenced record. In API security, the related term broken object level authorization, or BOLA, describes an API allowing someone to act on an object they are not authorized to use. A successful login does not establish permission to every invoice, document, or support ticket.
For a business, the useful assessment question is specific: can a customer who may view their own invoice retrieve or change an invoice belonging to another customer? Test the record boundary separately from which fields an authorized user may edit.
Which customer records should an IDOR assessment cover?
Begin with the objects that move through your product: orders, projects, attachments, subscriptions, saved reports, and membership requests. For each object, write down its owner and the roles allowed to read, change, share, or delete it.
Consider an illustrative procurement portal. A buyer can read invoices for its own company, an accountant can approve payment, and a supplier can upload supporting documents. These are three different relationships to the same invoice. A rule that merely checks whether someone belongs to any company leaves the business requirement unresolved.
Choose a representative record for each relationship. Include a deliberately shared record so that the assessment can distinguish an intended collaboration feature from unintended cross-customer access.
Are random IDs enough to protect private records?
No. Random identifiers make guessing harder, but the application must still check access when an identifier becomes known. OWASP’s IDOR prevention guidance explains why complex identifiers supplement authorization rather than replace it.
For the procurement example, an invoice link could appear in a forwarded email. Decide what the receiving user is allowed to see before testing the link. The security requirement should survive someone learning the address of a private record.
How do you test without exposing real customer data?
Create two synthetic companies with separate test users and clearly labeled records. First confirm that each user can perform the intended operation on their own records. Then use a known test record from the other company and observe the result.
Keep a small worksheet with the acting user, company, object, operation, expected decision, and observed outcome. Add a former member to test removal from a company. For sensitive operations, use reversible changes and inspect the stored result, not just a success message.
Stop at the agreed demonstration. A single synthetic cross-company disclosure can establish the flaw; downloading other customers’ records adds risk without improving the explanation.
Why should bulk actions and attachments be included?
A portal may use separate code for its invoice page, attachment download, and bulk approval. A passing result on one route leaves the others untested. Select those routes from the actual product workflow and document which were exercised.
For a bulk operation, mix an allowed test invoice with an unauthorized test invoice. Define whether the entire request should fail or whether the application may return a clearly separated partial result. Then verify that the unauthorized record remains unchanged and its private content is absent from the response.
What evidence closes an IDOR finding?
A useful report connects the test identity to the affected record, explains the missing business restriction, and shows the observed disclosure or change. After remediation, repeat the same case and a legitimate case using the deployed version.
For a Ceron assessment, provide the test roles, ownership rules, and synthetic records needed to establish those outcomes. Retain the access worksheet with the retest so engineering can use it when permissions change again.
For the separate question of permitted fields within a record, read API field permissions. Customer portal assessment scope covers the surrounding application. The procurement scenario is illustrative.
