When a Name Like “true” Breaks iCloud: Lessons on Boolean Parsing and Input Sanitization

Apple iCloud Registration Failure Due to Boolean Literal “true”

When a user entered the surname true (lower‑case) in the iCloud sign‑up form, Apple’s backend parsed the value as the Boolean literal true instead of a string. The server expects the lastName field to be a string, so the type mismatch caused the registration request to be rejected and the account was automatically locked for six months as a precaution against possible SQL‑injection attacks.

Technical cause

The input handling layer does not enforce string coercion for the lastName parameter.

Unquoted identifiers that match language keywords (e.g., true, false) are interpreted according to the server’s internal query language.

When the value is treated as a Boolean, the generated SQL (or internal data model) attempts to assign a Boolean to a VARCHAR column, which fails validation.

Mitigation strategies

Quote the surname value explicitly in the request payload, e.g. "lastName": "'true'", so the parser treats it as a literal string.

Update the server‑side validation to cast all incoming lastName values to strings before constructing queries.

If the service cannot be changed, the user must modify the surname to avoid reserved keywords.

Broader implications

The incident mirrors the classic “Bobby Tables” scenario where a name containing SQL syntax ( Robert'); DROP TABLE students) can break a database if not properly sanitized. Other surnames that have caused similar failures include Root , Self , Null , and van Os . These cases demonstrate two essential security practices:

All user‑supplied text must be escaped or parameterised before inclusion in queries.

Input validation should enforce type expectations (e.g., always treat lastName as a string).

Failure to apply these safeguards can lead to false positives for injection attacks, unnecessary account lockouts, and service denial.

Reference: https://twitter.com/RachelTrue/status/1368004197166108676