Why Using the String "null" as a Username Leads to Hidden Bugs

In many web applications, developers mistakenly treat the literal string "null" as if it were a null reference. This misunderstanding creates a hidden bug when a user submits a JSON payload like:

{
  "username": "null",
  "password": "123456"
}

The backend code often checks for a null reference using user.getUsername() == null. Because the incoming value is the non‑null string "null", the condition fails, allowing the registration to succeed with a username that appears as the word "null".

Consequences appear later when the system tries to send emails, assign permissions, or enforce uniqueness—operations that treat "null" as a legitimate identifier, leading to confusing errors and ghost‑like accounts.

To prevent this, validation should explicitly reject the string "null" (or any other placeholder values) in addition to checking for a true null reference. A robust check might look like:

String username = user.getUsername();
if (username == null || "null".equalsIgnoreCase(username) || username.trim().isEmpty()) {
    throw new IllegalArgumentException("Username cannot be empty or the literal \"null\"");
}

By handling both cases, developers ensure that only genuine, non‑empty usernames are accepted, eliminating the "ghost user" problem.