All research
Commentary · 5 min

When a Ticket System Lies: A Lesson in Trust, Technology, and Human Behavior

A personal encounter with a ticket office revealed how easily a technical interface can be manipulated to create a false sense of legitimacy—and how dangerous it is to assume that customers cannot see what is happening behind the screen.

Updated 2026-10-03

Sometimes the most interesting lessons in cybersecurity do not happen during a penetration test, a vulnerability disclosure, or a security conference. Sometimes they happen while you are simply trying to buy a ticket.

Buying a ticket home

During one of my trips to a country I will deliberately leave unnamed, I was trying to purchase a ticket back to Iraq. As is normal when traveling, I was not introducing myself as a programmer or security researcher. I was simply another customer looking for a ticket home.

I decided not to purchase the ticket through my phone and instead went to a licensed ticket office. I asked the employee for a ticket to Baghdad on a specific date and time. He checked his computer and told me that only three seats were remaining.

Then I noticed something unusual. The destination displayed on the screen was not Baghdad. It was Najaf.

I asked the employee about it, and he explained that the system had not updated yet and that this was normal. However, that explanation did not make sense to me. We were talking about a computerized booking system handling flight information, destinations, dates, and available seats. If the system was displaying one destination while the employee was verbally offering me a ticket for another, there was already a serious problem of trust.

I told him clearly that if I could not see Baghdad displayed in front of me, I would not take the ticket. I then left the office and assumed the situation was over.

What I saw through the glass door

The office had glass doors, however, and after walking outside I happened to look back while talking to the friend who was with me. I was about to tell him that I thought the employees were misleading us when I noticed something unexpected.

The employee was using the browser's developer tools. He was changing the text displayed on the webpage, replacing "Najaf" with "Baghdad" directly in the browser.

What had been explained to me as a system update was not an actual update to the booking data. It was simply a modification of what was being displayed on the screen.

Apparently, the assumption was that the customer would see the new text and accept it as proof that the problem had been resolved. What they did not know was that the person standing in front of them understood exactly what was happening.

A few moments later, they called me back and pointed at the screen, essentially saying, "Look, it is Baghdad now." I walked back inside, smiled, and left. I did not need to argue. The screen had already told me everything I needed to know.

The tool was not the problem

The interesting part of this incident is that the browser developer tools were not the problem. Developer tools are legitimate and essential tools used every day by developers, testers, designers, and security researchers. Changing text locally in a browser is also not, by itself, a sophisticated cyberattack.

The real problem was using a visual modification to create the impression that authoritative information had changed.

A webpage displayed on a computer screen is not automatically proof that the underlying database, reservation system, airline system, or backend contains the same information. A customer sees an interface, while a trustworthy system should ensure that important information is backed by authoritative data and can be independently verified when necessary.

This is where technology and social engineering intersect. The situation did not require malware, a server exploit, or an advanced attack technique. It relied on a much simpler assumption: the customer would believe what appeared on the screen.

That assumption can be surprisingly powerful.

The assumption about the customer

Perhaps the most concerning part of the experience was the apparent belief that the customer would not understand what was happening. Technology is everywhere now. The person sitting across the desk may be a programmer, system administrator, security researcher, engineer, or simply someone who understands how web applications work.

Even when a customer has no technical knowledge, that does not make deceptive behavior acceptable. A professional service should never depend on the customer's inability to understand the technology being used.

A trustworthy ticketing process should not rely solely on what an employee can visually display in a browser. Important booking information should be backed by authoritative records and, where possible, independently verifiable through a reservation reference, official ticket, itinerary, or another reliable verification mechanism.

Security also depends on trust

The broader lesson is that cybersecurity is not only about passwords, encryption, vulnerabilities, malware, or firewalls. Security also depends on trust.

When someone purchases a flight ticket, they are trusting the employee, the company, the booking system, and the information presented to them. If any part of that chain can be manipulated while the customer still believes everything is legitimate, the practical security of the entire process is weakened.

For me, the incident was not really about changing the word "Najaf" to "Baghdad." That was the easy part. The more important issue was the assumption behind it: "If it looks real on the screen, the customer will believe it."

In an increasingly digital world, that assumption is becoming less reliable. Perhaps one of the simplest lessons from this experience is this: never confuse what a screen displays with what a system actually knows.

Related research