When "null" Becomes a Real Username: Hidden Bugs and How to Prevent Them

You think null is the real null, but the bug is real!

I came across a funny post where a user chose the username "null". It's not the Java null or SQL NULL, but a literal string "null". This seemingly harmless value can cause serious bugs if your code doesn't treat it properly.

1. How funny is "null" for programmers?

Imagine you write:

if (username == null) {
    throw new IllegalArgumentException("Username cannot be null!");
}

Then the user submits:

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

Result? Your code doesn't catch it, and the user registers successfully.

Because "null" is a valid string, not the null value, your code never intercepts it, leaving a ghost user named "null" in the database.

The logs will show: Current user: null It looks like a system error, but it's just the username.

What problems does a "null" username cause?

User experience explosion: After login the system displays “Welcome, null!” leaving the user confused.

Log debugging hell: Logs are filled with null, making it impossible to distinguish real nulls from the string.

Database pollution: Exported data, permission management, or deduplication suddenly shows a "null" entry that looks like dirty data but is a legitimate registration.

Security risk: Some systems treat "null" as a special identifier, potentially leading to XSS or information leakage.

Automation script failures: Scripts that skip null values miss the "null" user, causing business logic errors.

How to deal with this issue?

Don't panic, here are some tricks:

(1) Strict username validation

Besides checking null, also block strings like "null", "undefined", empty spaces, etc.

private static final Set<String> ILLEGAL_USERNAMES = Set.of(
    "null", "undefined", " ", "\t", "
", "admin", "root"
);

public void validateUsername(String username) {
    if (username == null || ILLEGAL_USERNAMES.contains(username.trim().toLowerCase())) {
        throw new IllegalArgumentException("Invalid username!");
    }
}

(2) Front‑end interception

if (["null","undefined",""].includes(username.trim())) {
    alert("Username cannot be null or undefined!");
    return;
}

(3) Database constraints

ALTER TABLE users
ADD CONSTRAINT chk_username
CHECK (username NOT IN ('null','undefined',' '));

(4) Distinguish real null in logs

logger.info("Username: {}", username == null ? "[NULL]" : username);

Final advice: Don't let users pay for your code

Users may accidentally or automatically fill in "null", but you will be the one staying up debugging. Ensure entry interception, unified naming rules, and defensive programming.

Entry interception: Validate at registration, import, API calls.

Unified standards: Allow only letters, numbers, length limits.

Defensive coding: Always assume users will input the most bizarre data.

All programmers who have been trapped by "null", you are not alone. Next time you see "null", have a coffee ready – you might be debugging all night.