Why Calling Everyone a “User” Is a Hidden Security Risk

When a project’s initial lightweight assumptions turn out to be completely wrong after months of work, the root cause is often an imprecise model—most notably the overuse of the word “user.” The article shows why “user” is rarely a good description and how it introduces fundamental security flaws.

You Don’t Have "Users"

At the start, no software system truly has a generic “user.” Business logic is usually more complex, involving distinct concepts such as passengers, agents, and purchasers. In an airline reservation system, requirements include:

Passengers view reservations using a booking code.

Purchasers modify reservations with the last four digits of a credit‑card number.

Travel agencies can view and edit their bookings.

Airline check‑in staff access reservations based on role and airline, requiring passenger identity verification.

These roles illustrate that “user” is an unhelpful abstraction; the system must handle specific entities and their credentials.

Unix Has No "Users"

Even in POSIX systems, the term “user” groups together disparate entities: interactive logins, system services (e.g., nginx running as the httpd user), shared admin accounts on cloud VMs, and the root account. Treating all of these as “users” obscures their differences and creates security gaps, such as the inability to restrict access to only Alice and Bob.

SaaS Providers Have No "Users"

In SaaS, a paying individual belongs to an organization, and one or more people actually use the service. If you model them all as a single “user,” you lose the ability to represent teams, shared billing, and multi‑person usage, forcing costly redesigns later. The useful abstraction collapses to two concepts: a team (for relationships and payment) and members (the actual service consumers).

"Users" Are a Security Problem

The ambiguity of “user” merges two distinct ideas: a person and their representation in software. This conflation can lead to attacks like the Confused Deputy problem, where a browser running under a system account can upload files on behalf of the human user, making the system appear to act on the user’s intent when it does not.

Why It Happens

Because the browser runs with the same system identity as the human, any operation performed by the browser is attributed to the user, even malicious actions. Using a single “user” concept makes such privilege‑confusion attacks more likely.

The Value of Early Design

Spending a few hours upfront to define precise terminology and concepts saves far more effort later. Starting to code immediately with vague terms like “user” seems productive but actually leads to extensive rework and security issues. Future developers will thank you for the early investment.