How do you use safe object deserialisation APIs in mobile apps?

Use safe deserialisation APIs by allowing only expected classes or data shapes and rejecting unknown or unexpected types. Avoid generic object reconstruction from untrusted input, because attackers can abuse it to trigger logic flaws or unsafe object creation. Prefer simple, explicit data formats, and validate the resulting object before using it in security-sensitive code.

How safe deserialisation APIs should be designed in mobile apps

Safe deserialisation is less about the storage format itself and more about what the app is allowed to reconstruct from it. In mobile apps, the safest pattern is explicit schema-driven parsing: the input should map to known fields and expected data types, not to arbitrary runtime objects. That keeps parsing deterministic and makes downstream validation and review much easier.

The practical design choice is to treat deserialisation as data handling, not object recovery. That means preferring JSON or another simple structured format with a fixed model, using allowlists for permitted classes or types where the platform requires object mapping, and rejecting anything with unknown members, unexpected polymorphism, or nested structures that the app does not need. Insecure Deserialisation Guide is the right deeper reference when you want the broader attack patterns behind that rule.

Mobile teams should also keep deserialisation close to the boundary of the app, before any business logic sees the object. That lets you validate the result as an input artifact, not as a trusted internal object. If a field controls permissions, file paths, account linkage, feature access, or any other security-sensitive branch, validate it again after parsing and before use. This matters because a deserialised object can be syntactically valid and still be unsafe for the action you intend to take.

Why unsafe object reconstruction becomes dangerous on mobile

Unsafe deserialisation fails when the app assumes that a parsed object is trustworthy just because it came from a local file, a network response, or an IPC boundary. On mobile, those inputs are often easier to influence than teams expect, especially when apps cache state, sync content, or accept payloads from webviews, deep links, companion services, or backend APIs. A parser that reconstructs arbitrary objects can turn crafted input into logic manipulation, gadget-chain style behaviour, or object state that bypasses intended checks.

The risk is amplified when object construction has side effects, invokes callbacks, or triggers framework behaviour during initialisation. Even if the app never explicitly calls a dangerous method, the act of recreating the object can alter control flow or load unexpected classes. That is why explicit data transfer objects are safer than generic object graphs, and why deserialisation filters matter most when the platform defaults are permissive. The same principle underpins API security guidance such as OWASP API Security Top 10, which is useful when the mobile app is consuming untrusted API payloads.

Mobile environments also make abuse harder to notice because the failure may look like a normal crash, a malformed sync record, or a feature-specific bug. If the object format can be replayed or tampered with offline, attackers may be able to test payloads repeatedly until they find a type or field combination that changes app behaviour. That is why safe deserialisation is not only about preventing remote code execution, it is also about stopping trust-boundary mistakes in everyday app logic.

What good mobile app implementation looks like in practice

A good implementation starts with narrow parsing rules. Use a parser that only accepts the shapes you expect, binds to explicit model classes, and rejects unknown or ambiguous types rather than coercing them. If your platform offers safe mode, type allowlisting, or serializer configuration to disable polymorphic reconstruction, enable it and keep it on by default. For object stores, caches, and persisted state, prefer versioned, plain data models that are easy to migrate and easy to inspect.

Next, validate the reconstructed object before it reaches privileged code. Check invariant fields, enforce length and range limits, confirm referenced identifiers are legitimate, and discard any object that fails business rules even if the parser accepted it. When the payload affects authentication, authorisation, local storage, or remote requests, treat deserialisation output as untrusted input until the full validation path is complete. The most common mistake is to validate the raw payload format but not the semantic meaning of the resulting object.

For teams that need a broader mobile security control baseline, Mobile App Security Guide and Mobile App Security Testing Guide help place deserialisation inside the wider mobile threat model, where storage, attestation, and runtime tampering also affect trust in the parsed object.

Risk and Threat Considerations

Unsafe deserialisation turns trusted object construction into an attack surface. The main risks are object injection, logic bypass, and unintended class activation, especially where the app accepts data from network responses, local persistence, or inter-app channels that can be influenced or replayed.

Failure mechanism: The parser reconstructs a richer object than the application intended, or it accepts a type that carries executable behaviour, state transitions, or privileged fields that should never have been set by external input.

Impact: Attackers can alter app logic, force unsafe state, or chain parsing behaviour into broader compromise of account data, session state, or backend requests made by the mobile client.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V4 — API and Web Service	Mobile apps often deserialize untrusted API responses into app objects.
	V15 — Secure Coding and Architecture	Safe deserialization depends on explicit data models and avoiding unsafe object construction.
Recommendation — Validate API inputs and reject unexpected object shapes before deserialization. Use explicit DTOs and eliminate generic object reconstruction from untrusted input.
CIS Controls v8	CIS-16 — Application Software Security	Deserialization safety is a secure development concern for mobile application code.
Recommendation — Review mobile parsing code for unsafe object creation and enforce secure coding standards.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	Unknown or unexpected types are an input-validation failure at the deserialization boundary.
	SA-11 — Developer Testing and Evaluation	Safe deserialization should be tested for unsafe type handling and object injection paths.
Recommendation — Validate deserialized data against expected types and reject malformed input. Test deserialization paths for unexpected classes, fields, and payload mutations.

Practitioner Guidance

What to verify: Confirm that every deserialisation entry point has an explicit type allowlist, a fixed schema, or both, and that unknown fields fail closed rather than being silently accepted. If a library supports polymorphism by default, disable it unless you have a documented need and a bounded trust model.

Decision rule: If the parsed object can influence authentication, authorization, payments, account state, or server requests, treat deserialisation as a security control point, not a convenience layer. The validation step should be mandatory before the object is used anywhere privileged.

Practitioner takeaway: The safest mobile deserialisation strategy is to reconstruct only the minimum data shape you need, then prove it is safe before any business logic trusts it.