Why a Username of "null" Can Break Your System and How to Prevent It

The article discusses the hidden dangers of accepting the literal string "null" (or similar edge values) as a username in backend systems.

Problems caused by a "null" username

1. User experience

When a user sees a greeting like "Welcome, null!", it is confusing and may be mistaken for a system placeholder; users often do not understand why their name appears as "null".

2. Development and maintenance

Logs that contain "null" cannot be easily distinguished from a true null value, making debugging difficult. Automated scripts may treat the string specially, leading to missed records or incorrect processing.

Duplicate‑check, Excel export, and permission audits see "null" and cannot tell if it is abnormal data.

Many automation tools have custom handling for "null" and may skip or mis‑classify such users.

3. Security

Attackers can exploit boundary values such as "null", "undefined", spaces, or emojis to probe validation logic, potentially triggering XSS or information‑leakage vulnerabilities when these strings are interpreted as system variables or placeholders.

4. Consistency and standards

If "null" is allowed, other ambiguous identifiers like "undefined", "0", blank spaces, emojis, or reserved words like "admin" become questionable, breaking naming conventions and data hygiene.

5. Troubleshooting

Typical investigation steps include packet capture, log inspection, adding breakpoints, clearing caches, and examining the database. Often the root cause is that the stored value is the string "null" rather than an actual null, leading to hours of unnecessary debugging.

How to handle it correctly

From a technical standpoint, the string "null" is a valid non‑empty string and will not trigger a null check, but from product, security, and operations perspectives it should be treated as illegal input and blocked at the entry point.

private static final Set<String> ILLEGAL_USERNAMES = new HashSet<>(Arrays.asList(
    "null", "undefined", "true", "false", "admin", "root", "", " ", "\t", "
"
));

public void validateUsername(String username) {
    if (username == null || ILLEGAL_USERNAMES.contains(username.trim().toLowerCase())) {
        throw new IllegalArgumentException("用户名非法或为空");
    }
}

The example demonstrates a simple whitelist of illegal usernames and a validation method that throws an exception when the input is null or matches any prohibited value.

In practice, regardless of whether the data comes from front‑end forms, Excel imports, or external APIs, the same rule applies: validate first, then process, to avoid downstream bugs and security issues.