Picture this: It’s the final match of the FIFA World Cup. Billions of eyes are glued to screens around the globe. The stadium is packed, the tension is palpable, and suddenly, the giant stadium screens flash. Instead of the starting lineups or a crucial VAR review, Rick Astley starts dancing to "Never Gonna Give You Up."
According to a mind-blowing security disclosure that recently topped Hacker News, this wasn't just a fever dream—it was a highly plausible reality. Security researcher Sam Curry revealed how he discovered a massive vulnerability in the Hayya portal (the mandatory fan ID visa system used for the Qatar 2022 World Cup) that allowed him to bypass document verification entirely. He didn't need a sophisticated zero-day or a quantum computer. All he needed was his own ID, a proxy tool, and a fundamental misunderstanding of API security on the developers' part.
As developers, we often focus on complex cryptography, SQL injection, or cross-site scripting (XSS). But this incident highlights a much more common, insidious threat: broken object-level authorization (BOLA) and flawed client-side validation logic. Today, we’re going to dissect exactly how this vulnerability worked, why it happened, and how you can prevent your own APIs from making the front page of Hacker News for all the wrong reasons.
The Anatomy of the Vulnerability: What Went Wrong?
To enter Qatar and access World Cup stadiums in 2022, every attendee needed a "Hayya Card." The application process required users to upload a high-quality scan of their passport or government ID. This wasn't just a dummy upload; an automated OCR (Optical Character Recognition) system, backed by human reviewers, validated the data on the ID against the application form.
If you tried to upload a picture of a cat, or a photo of Rick Astley, the system was supposed to reject it immediately. And indeed, if you tried it through the browser, it did. But as web developers, we know a golden rule that the creators of the Hayya portal seemingly forgot: The frontend is a hostile environment. You can never trust the client.
Step 1: The Client-Side Gatekeeper
When a user uploaded an ID, the frontend application sent the image to an validation API. This API returned a JSON payload indicating whether the ID was valid, along with the extracted OCR data (like name, passport number, and date of birth).
If the validation succeeded, the frontend enabled the "Submit" button and populated the hidden form fields with the OCR data to send to the backend registration database. If it failed, the frontend blocked the user.
Step 2: Intercepting the Response
Curry realized that the actual state of "validity" was being determined and acted upon by the React/Angular frontend, rather than being enforced statelessly on the backend during the final form submission.
By using an intercepting proxy like Burp Suite or OWASP ZAP, he uploaded a completely fake image (which failed validation) and simply intercepted the HTTP response from the validation server. He changed the failure response to a success response:
{
"status": "failed",
"error": "Document unrecognized"
}...was modified in transit to look like this:
{
"status": "success",
"ocr_data": {
"first_name": "Rick",
"last_name": "Astley",
"passport_number": "A12345678",
"birth_date": "1966-02-06"
}
}Step 3: The Fatal Backend Flaw
When the browser received this modified "success" response, the frontend UI happily unlocked the form and allowed Curry to click "Submit."
This is where the catastrophic failure occurred. The backend endpoint that handled the final registration form submission did not re-verify the ID or check if the OCR transaction ID matched a successful validation token generated securely on the server. It simply trusted the data sent by the client's browser. Curry was able to register a completely fake profile with a fake ID, bypassing a multi-million dollar border control and ticketing security system.
Why Client-Side Validation is Only for UX
It is incredibly easy to fall into this trap when building modern Single Page Applications (SPAs). We want to create snappy, responsive user interfaces. We want to show instant validation feedback to the user without making slow round-trips to the database.
However, we must always maintain a strict mental separation between UX Validation and Security Validation.
- UX Validation (Frontend): Helps honest users fill out forms correctly. It prevents typos, ensures password strength requirements are visible, and guides the user. It is purely cosmetic.
- Security Validation (Backend): Assumes the user is a malicious actor who has bypassed the frontend entirely using
curlor Burp Suite. It enforces business logic, access control, and data integrity.
Designing a Secure ID Verification Architecture
Let's look at how we should architect an ID verification flow to prevent this type of bypass. We need to ensure that the backend registration endpoint cannot be fooled by tampered client-side data.
The Secure Workflow
Instead of relying on the client to pass the OCR results back to the registration endpoint, we should use a stateful, token-based verification flow. Here is a conceptual architecture:
- Upload: The client uploads the ID document directly to a secure, temporary S3 bucket or a backend upload endpoint.
- Process: The backend initiates the OCR/validation process asynchronously or synchronously.
- Token Generation: Upon successful validation, the backend saves the validated OCR data in a secure database/cache (e.g., Redis) mapped to a cryptographically secure, random
verification_token(UUIDv4) with a short TTL (Time to Live). - Response: The backend returns only the
verification_tokenand the necessary UX data to the client. - Submission: When the client submits the final registration form, they send only the
verification_token. - Server-Side Resolution: The backend looks up the
verification_tokenin the secure cache, retrieves the trusted OCR data, and completes the registration. The client never has the opportunity to manipulate the OCR data.
Architecture Diagram
[Client Browser] ----(1. Upload ID)----> [Validation API]
|
(Processes ID)
|
[Client Browser] <---(2. Return Token)--- [Validation API]
| (Saves Token -> OCR Data in Redis)
|
(3. Submits Form + Token)
|
v
[Registration API] ---(4. Verify Token)---> [Redis Cache]
| |
|<-------(5. Return OCR Data)------------|
|
(6. Saves Verified User to DB)
Implementation Example: Node.js/Express Secure Verification
Let's write a simple Express backend that implements this secure token-based verification pattern. This ensures that even if a developer intercepts the client-side code, they cannot forge their identity details.
The Insecure Way (Don't Do This!)
This mock controller mimics the flawed Hayya system. It trusts the client to tell the backend what the OCR results were.
// INSECURE: Trusting the client payload
app.post('/api/register-insecure', (req, res) => {
const { username, userSubmittedOcrData } = req.body;
// The backend blindly trusts that userSubmittedOcrData
// was validated by the frontend/OCR service.
db.saveUser({
username,
realName: userSubmittedOcrData.fullName,
passportNumber: userSubmittedOcrData.passportNumber,
isVerified: true
});
res.status(201).send("Registration successful!");
});The Secure Way (Do This!)
Now, let's write the secure version. We split this into two steps: initiating/validating the ID, and then using the server-generated token to complete the registration.
const express = require('express');
const { v4: uuidv4 } = require('uuid');
const redis = require('redis'); // Used to store temporary verification states
const client = redis.createClient();
const app = express();
app.use(express.json());
// Step 1: Secure ID Upload & Validation Endpoint
app.post('/api/verify-id', async (req, res) => {
try {
const { idImageBase64 } = req.body;
// 1. Send the image to your trusted OCR / Identity Verification Partner API
const ocrResult = await externalIdentityValidator.check(idImageBase64);
if (!ocrResult.isValid) {
return res.status(400).json({ error: "Identity validation failed." });
}
// 2. Generate a secure, single-use token
const verificationToken = uuidv4();
// 3. Store the trusted OCR data in Redis with a 15-minute expiration
const sessionData = {
fullName: ocrResult.extractedName,
passportNumber: ocrResult.passportNumber,
dateOfBirth: ocrResult.dob,
status: "VERIFIED"
};
await client.setEx(`id-verify:${verificationToken}`, 900, JSON.stringify(sessionData));
// 4. Return the token (and safe UX-only data) to the client
res.json({
success: true,
token: verificationToken,
preview: { fullName: ocrResult.extractedName } // Only for UI rendering
});
} catch (error) {
res.status(500).json({ error: "Internal validation error" });
}
});
// Step 2: Secure Final Registration Endpoint
app.post('/api/register-secure', async (req, res) => {
const { username, verificationToken } = req.body;
// 1. Fetch the token data from our trusted Redis store
const cachedData = await client.get(`id-verify:${verificationToken}`);
if (!cachedData) {
return res.status(400).json({ error: "Invalid or expired verification session." });
}
const verifiedIdData = JSON.parse(cachedData);
// 2. Double check the verification status
if (verifiedIdData.status !== "VERIFIED") {
return res.status(403).json({ error: "ID has not been successfully verified." });
}
// 3. Save to database using the TRUSTED data we retrieved from Redis
await db.saveUser({
username: username,
realName: verifiedIdData.fullName, // Safe from client manipulation
passportNumber: verifiedIdData.passportNumber, // Safe from client manipulation
isVerified: true
});
// 4. Invalidate the token so it cannot be reused (Single-Use Token Pattern)
await client.del(`id-verify:${verificationToken}`);
res.status(201).json({ success: true, message: "User registered securely!" });
});Key Takeaways for Developers
The FIFA World Cup vulnerability is a classic reminder of the responsibilities we bear when building APIs. When you are writing code this week, keep these three security tenets in mind:
1. Never Rely on Client-Side State for Security
If your backend security relies on the assumption that "the frontend wouldn't allow this," your system is vulnerable. Assume that every request hitting your API was hand-crafted by an attacker using a command-line terminal.
2. Implement Single-Use, Short-Lived Tokens
When dealing with multi-step processes (like uploading an ID, checking a payment status, or verifying an SMS code), always generate a cryptographically secure token on the backend to link the steps together. Store the state of that process on your servers, not in the user's browser storage or session.
3. Use Pentesting Tools on Your Own Work
Before you push to production, fire up an intercepting proxy like OWASP ZAP or Burp Suite. Intercept your backend requests, change "success" to "failed" (and vice versa), manipulate IDs, and see how your API reacts. If your application still processes the transaction when you feed it modified server responses, you have work to do.
Conclusion
Thankfully, Sam Curry disclosed this vulnerability responsibly, and the FIFA coordinators patched it before malicious actors could exploit it at scale. But the fact that such a critical system, launched on a global stage, fell victim to a simple client-side bypass is a wake-up call for all of us.
Have you ever encountered a similar client-side validation bug in the wild? How do you handle multi-step form verification in your current stack? Let’s chat in the comments below!
If you enjoyed this deep dive, don't forget to subscribe to the "Coding with Alex" newsletter for weekly breakdowns of real-world security incidents, system design deep dives, and clean coding practices.