Export and "download all" features are genuinely useful, letting a user pull their own data out as a spreadsheet or file in one click. They're also a specific place worth checking separately from ordinary browsing, because a feature built to fetch "a lot of records at once" is exactly the kind of feature that can be pointed at more than it was meant to reach.
Why bulk features carry a different risk than single-record views
A single-record IDOR gap exposes one record at a time, someone has to change one ID and check the result manually. A bulk export feature that has the same underlying gap can expose an entire dataset in a single request, since the whole point of the feature is fetching many records at once. The scale of what's exposed is completely different, even when the underlying mistake is the same kind of missing check.
A concrete way this shows up
An export feature meant to let a business owner download their own customer list might accept an account or organization ID as part of the request. If that ID can be changed, the same way a single record's ID can be changed, and the feature doesn't verify the requester actually owns that account or organization, changing the ID could return someone else's entire customer list in one export, rather than a single row.
How to test your own app
- Find any export, download-all, or bulk-fetch feature in your app.
- Inspect the actual request it sends, looking specifically for any ID identifying which account or organization's data is being requested.
- If you find one, try changing it to a different test account's ID and see whether the export still succeeds, and with whose data.
- If your app has any admin or reporting feature that pulls data across multiple users, check that it's restricted to admins specifically, not reachable by a regular account that happens to know the right request shape.
Why this deserves its own specific check
Bulk features often get built later than the core app, added as a convenience once the basic single-record version already works, and it's easy to build the bulk version by extending the same logic without re-verifying that ownership checks scale up correctly to "many records" the same way they applied to one. Worth testing this specifically, separately from your regular walkthrough, given how much more a single successful request can expose.