Why the Word ‘User’ Is a Hidden Security Hazard in Software Design

When you realize that the lightweight, simple assumptions made at the start of a project were completely wrong after six months, you have already invested a lot of time and now need to solve these problems to keep the system running; proper initial design would have prevented this.

Today I want to tell you about a common mistake that brings endless problems: the word “users”.

This word has two fundamental errors:

For your requirements, “User” is rarely a good description.

“User” leads to a basic design security flaw.

The concept of “user” is vague; using more precise terminology almost always works better.

You Don’t Have Users

Initially, no software system truly has users. “User” seems like a good description, but the business logic is actually much more complex.

I will use three examples, starting from an extreme case.

Ticket Booking System Has No “Users”

I once wrote access‑control logic for a ticket‑booking system, with requirements such as:

Travelers can use a reservation code to view booking information on the website.

Buyers can modify reservations on the website using the last four digits of their credit‑card number.

Travel agencies can view and modify their bookings.

Airline check‑in staff can view and modify reservations based on role and airline, requiring the traveler to provide identity information.

These concepts are “traveler”, “agent” (the website can be seen as an agent), and “buyer”, not a generic “user”.

Unix Has No “Users”

Unix (now often called POSIX) has users who can log in and execute code. Looking deeper:

System services like nginx can run as the “httpd” user.

Many people share an administrator account for SSH (e.g., Ubuntu’s default “ubuntu” account).

Root is a distinct identity.

These are almost different concepts, but on POSIX they are all called “users”, which leads to many security problems.

SaaS Providers Have No “Users”

Jeremy Green recently posted about user models in SaaS, noting that SaaS services are almost always:

An organization where one person pays for the service.

One or more people jointly using the service.

If you treat these people as a single “user”, you cannot build a team model or a shared‑payment model, forcing you to refactor the system later. The “user” concept is too vague; you really need only two concepts: a team (for relationships and payment) and a member (the actual service user).

“Users” Are a Security Problem

The word “user” not only confuses business logic but also creates a series of security issues by merging two fundamentally different concepts: a person and their representation in software.

To illustrate, imagine visiting a malicious website that causes a browser memory overflow; the remote site then uploads your files to its server because the browser runs under your system user account, which is treated as the same “user”. This is the Confused Deputy problem.

The Value of Early Design

Spending less effort on the same problems is the key to becoming a highly productive programmer. Using vague concepts like “user” to organize your software will waste a lot of time and energy solving future issues. Jumping straight into coding may look productive, but the opposite is true.

Next time you start a new software project, spend a few hours upfront defining your terminology and concepts: you won’t be perfect, but you’ll do better, and your future self will thank you for the preventive work.