How the 2026 FIFA World Cup was almost hacked (and how Softr could've prevented it)

A security researcher recently found a critical flaw in the infrastructure behind FIFA's 2026 World Cup, one that could’ve let an attacker shut off or hijack live broadcasts worldwide. And it wasn't exotic code or some obscure legacy system. It came down to a single mistake: trusting the frontend to enforce security.

What happened

FIFA runs a public registration platform for football agents. You sign up, verify your email, upload an ID, and you're in. This sounds harmless on paper, except every registration automatically added the account to FIFA's Microsoft Entra tenant, the same identity system behind its internal apps, including the production streaming infrastructure for the World Cup.

The user registered, then tried to open FIFA's Football Data Platform. The system authenticated them and showed a tidy message: "You do not have any role assigned to your account." Access denied. 

But while it looked like the system was working, it wasn't. That "access denied" page was rendered entirely in the browser. The Angular frontend checked the token for a role, found none, and drew an error screen. The backend APIs never checked roles at all. They served whatever was asked. 

So, when the researcher bypassed the frontend check, the backend handed over the entire Streaming Management dashboard: every match, camera feed, RTMP ingest URL, and stream key.

Here's the whole chain of events laid out:

• Register on FIFA's public agent platform, open to anyone.
• Land in FIFA's Microsoft Entra tenant automatically, right next to its internal apps.
• Open the Football Data Platform, where the frontend politely says "access denied."
• Bypass the client-side check, since the denial only ever lived in the browser.
• Get everything from the backend: live match controls, camera feeds, RTMP ingest URLs, and stream keys.

In plain terms, someone could theoretically have rickrolled the World Cup—live, on every network broadcasting the tournament—because a public sign-up form reached production systems and the only lock was a check that ran in the browser.

The researcher reported the flaw instead of exploiting it, and FIFA patched it within a day. But the fact that the error happened at all is the story.

Why it happened

This kind of problem isn't rare. It's called broken access control, and it shows up constantly in software that's built on shaky infrastructure. But what made this particular mistake remarkable was the scale. We’re talking about the World Cup here, the most-watched broadcast on the planet, not a weekend coding project.

Here’s how Softr’s Co-Founder and CTO Artur Mkrtchyan breaks down the issue:

“Think of the difference between locking a door and just putting up a "Staff Only" sign. Vibe-coding platforms that lean on LLMs tend to reach for the sign. Ask one to restrict a page, section, or button, and it'll usually show an "access denied" message or hide the item from view. This looks like security but isn't, because the door behind it is still unlocked. Anyone willing to ignore the sign and try the handle gets straight in. That's what happened to FIFA: the "access denied" page was just a sign, and the door was never locked.”

A lot of this comes down to how an app gets built. Prompt a vibe-coding tool for a restricted admin view, and what the model produces is usually just a frontend check. But because the rule lives in the browser, it can be switched off. Permissions become UI chrome, not a real gate on the data.

💡 We broke down how different platforms manage vulnerabilities in our list of the most secure vibe coding tools for enterprise teams.

A different approach: Enforce security on the server

Platforms built on a fixed, server-side permission model work differently. The access rule isn't reinvented for every prompt or bolted onto the interface after the fact. It's enforced on the backend, the same way every time, before any data is returned. If a user lacks permission, the request fails and access is denied before it ever reaches the data.

Artur describes what that looks like in Softr apps:

“Softr enforces security on the server. Instead of hiding things on the screen, it checks who you are before any data leaves the server. Every app is built on the same set of user groups, and each group gets its own rules about what it can see and do. When someone opens a page, the server asks "is this person in a group that's allowed to see this?" before it sends anything back. If the answer is no, the data never travels.”

How Softr enforces permissions

Rather than generating one-off access logic for every prompt, every Softr app shares the same user groups and permissions model:

• User groups define who's who: clients, employees, admins. Groups can be dynamic (assigned automatically by a user attribute or plan) or static lists you manage by hand, and every other rule keys off them.
• Page and block visibility controls which pages, blocks, and action buttons each group can see, so people aren't shown parts of the app that were never meant for them.
• Action permissions decide who can create, edit, or delete records, not just who can view them.
• Conditional filters scope records to the logged-in user, so people only ever load their own data. A client sees their own projects; they can't pull anyone else's.
• Global data restrictions let you set a view, create, edit, or delete rule once and have it apply across every block automatically, so a single forgotten block can't quietly leak data.

Those data rules are enforced server-side, before records are returned, rather than painted over in the interface. And because the permission model is fixed rather than regenerated from a prompt, there's no new code path shipping data to the wrong user.

Don't be the next FIFA — build business apps with Softr

The FIFA case is unambiguous—production streaming keys, reachable from a public app—but the same pattern repeats all the time. 

Here’s how Artur has seen it play out in real business scenarios: 

“I've watched this break in ordinary places: an HR portal hiding the salary page that anyone could still load, a support tool where customers could read each other's tickets by trying the next ID. None made headlines. They didn't need the World Cup's audience to be a real problem for the people whose data leaked.”

Thankfully, the lesson is simple. Build on a platform that enforces permissions on the server, and this kind of disaster mostly disappears. Build on one that hides them in the frontend, and you're one crafty user away from FIFA's near-miss.

Want to build software on infrastructure that enforces permissions where it really counts? Try Softr for free.