OWASP Top 10 - Broken Access Control

August 10, 2026

I recently went to my very first festival ever. It didn't quite win me over at first — though I might give it another shot next year. What really stuck with me, however, wasn't the music or the crowd, but what I found buried in its payment and ticketing infrastructure.

Disclaimer: This issue was reported to the affected provider through responsible disclosure. All screenshots and examples shown here have been anonymized or replaced with sample data — no real personal information, credentials, or payment details are exposed. My goal is not to shame anyone, but to help other developers avoid the same class of mistake.

The platform in question is a white-label solution that provides ticketing for quite a number of events. What I found was a broken access control vulnerability — and while I can't fully explain why, in my experience it's one of the most common and most dangerous security concerns out there.

In this particular case, a migration was underway to a new dashboard while the old one was still actively in use. Features were being partially replaced by the new system, and on the surface everything seemed fine.

But there was a fundamental mistake: any user could create an account on the website and gain access to the dashboard — without proper monitoring or restrictions in place.

At some point, the developers had implemented a feature that logged every change made to an object: who changed it, when, and a full snapshot so the object could be restored in the database. That's a perfectly common use case. The horrifying part is that it was released without proper access management — meaning anyone with a signed JWT could retrieve essentially any object from the database.

For example, the exposed objects were Companies, Coupons, Events, Metadata, Orders, Products, Shops, and Tickets - basically everything.

Company Object: payment insights Company

User Object: telephone number, email, and hashed password User

Here's where it gets even worse. Because the change-tracking schema always stores the ID of the user who made the change, every logged object effectively leaks another identifier back into your hands. By following those IDs from one record to the next, you can enumerate users you were never meant to see — piece by piece reconstructing large parts of their entire database from a single signed JWT.

Stay safe 🖖

🏳️‍🌈