Kotlin 2.4

Apply these rules to Kotlin 2.4 across JVM, Android, Native, JavaScript, and multiplatform code. Static nullability and sealed types improve design but don't validate values crossing runtime boundaries. Keep platform-specific security guarantees explicit in expect and actual implementations and at every interop boundary.

Nullability and type modeling

• Never use !! on values derived from input, configuration, lookups, interop, deserialization, or asynchronous state.
• Model authentication, authorization, ownership, and validation outcomes with closed sealed types rather than nullable values or booleans.
• Use value classes or dedicated types to distinguish validated identifiers, paths, URLs, tokens, and tenant-scoped keys.
• Reject unknown enum and sealed-state values from external systems instead of selecting a permissive default.
• Keep raw boundary models separate from validated immutable domain models.

Input validation and conversion

• Validate length, syntax, encoding, range, and allowed values before converting attacker-controlled text.
• Use exact, locale-independent parsing for protocol numbers, dates, identifiers, and security decisions.
• Validate signs, leading zeros, and application bounds around toIntOrNull, which already rejects surrounding whitespace and values outside the Int range.
• Reject unknown fields and mass-assigned privileged properties in request and message models.
• Normalize values only after basic validation and authorize the same canonical representation later used for access.

Serialization boundaries

• Treat decoded