Why the Word “User” Is a Hidden Security Risk in Software Design

Why the generic term “user” is problematic

Using the vague concept “user” to model actors in software often leads to two systematic errors:

It does not accurately describe the real‑world entities required by the business logic.

It conflates a human being with the software identity that represents the human, creating security gaps such as the Confused Deputy problem.

Concrete domain examples

Ticket‑booking systems

Typical requirements for a flight reservation service are:

Passengers view reservation details using a booking code.

Buyers modify reservations by providing the last four digits of their credit‑card number.

Travel agencies view and edit the bookings they manage.

Airline check‑in staff access or change reservations based on role and airline, after verifying passenger identity.

These interactions involve distinct roles— passenger , agent (the website acting on behalf of a travel agency), and buyer . Modeling them as a single “user” adds no value and obscures the required credentials (e.g., passenger ID, agency token) that must be present in each request.

Unix/POSIX environments

POSIX defines “users” as accounts that can log in and execute code, but in practice the term covers several unrelated concepts:

System services (e.g., nginx running as the httpd user).

Shared administrative accounts (e.g., the default ubuntu SSH account on Amazon EC2 instances).

The privileged root account, which has a different security model.

Grouping these disparate identities under a single “user” umbrella makes it difficult to enforce fine‑grained policies such as “only Alice and Bob may log in via this account”, and it can lead to the Confused Deputy issue because the operating system cannot distinguish between a human operator and a service process.

SaaS platforms

In most SaaS products the paying entity is an organization , while the actual consumers are one or more members . If all members are modeled as a single “user”, the platform cannot represent team structures, shared‑billing arrangements, or role‑based access controls without a costly redesign later. A more accurate model separates:

Team : the logical grouping used for billing and relationship management.

Member : the individual who authenticates and performs actions.

Security implications of the “user” abstraction

The term merges two distinct layers:

The physical human being.

The software principal that acts on the human’s behalf.

When a browser runs under a system account, the operating system treats actions performed by the browser as if they were initiated by the human user. An attacker who compromises the browser can therefore cause the system account to perform privileged operations—this is the classic Confused Deputy scenario. Using a single “user” label for both layers makes such mismatches more likely to be overlooked during design.

Design recommendations

Spend time early in a project to replace the generic “user” with precise domain concepts:

Identify the real actors (e.g., passenger, agent, buyer, admin service, organization).

Define separate identity objects for authentication (human credentials) and authorization (role, permissions).

Model SaaS billing entities as teams and operational actors as members .

Clear terminology reduces ambiguity, simplifies access‑control policies, and prevents security regressions that would otherwise require extensive refactoring.

Source: 21cto.com/article/2093