The Navigation 3 Blind Spot: Why your backstack might be leaking data

The old model: why intents mattered

For a long time, Android security guidance had a clear center of gravity: entry points. Activities, services, receivers and the intents that reach them. If another app could send something to your component, that was the boundary to study.

That focus made sense. In the classic multi-activity model, each screen was often its own component, and the operating system decided how users and other apps moved between them. Navigation was largely something the platform did to your app.

Many checklists and review habits were built in that era, and they are still useful. The risk is the quiet assumption that “we reviewed the intents” means “we reviewed navigation”.

The new model: navigation state as data

Modern apps tend to look different. A single host, declarative screens, and a navigation library that keeps the list of destinations in memory as ordinary data. The backstack is no longer something the platform manages on your behalf. It is a structure your own code builds, reads and changes.

That is a real improvement for developers. It is easier to test, easier to reason about, and easier to restore. It also moves the risk.

Once navigation state is data, it can carry data. Destinations often hold arguments, identifiers or whole models. Those objects can end up in places the original design never considered: saved state, logs, crash reports, analytics events. And access to a screen is now a question your app answers itself, rather than one the operating system answers for you.

The questions worth asking shift accordingly. Not only “who can reach this component?” but “what does this route require, who enforces it, and where does this state go?”

Synthetic failure modes

Three patterns we see as typical failure modes when navigation is state.

• Sensitive data in navigation state. A destination carries a full record instead of an identifier. That record now travels wherever navigation state travels: persistence, diagnostics, logs. Data that was meant to live for one screen outlives it.

• Route access controlled by the UI only. A protected screen is hidden from menus and buttons, but the route itself does not check authorization. Anything that can place that destination into navigation state, such as a restored session, a deep link or an unexpected transition, may find the door open.

• Stale sensitive data on the way back. After sign-out, an account switch or a session expiry, the user navigates back and a previous screen still renders what it held before. The state changed, but the screens behind it were never told.

None of these needs an exotic flaw. They come from reasonable design choices that were reviewed one at a time, but never as a whole.

Why this matters

These patterns tend to sit in the flows that carry trust: account details, payments, personal data, anything that changes with who is signed in. They are also easy to miss, because every individual screen works as designed.

Teams that rely on intent-focused reviews, or on endpoint testing alone, can end up with a tidy report that never looked at navigation. The server may enforce everything correctly while the client still exposes what it already downloaded.

• Privacy exposure. Personal data shown to the wrong session, or stored in places with a wider audience than the screen.

• Deal friction. A security review asks how routes and state are protected, and the honest answer is “we have not looked”.

• Late, expensive fixes. Moving data out of navigation state touches many screens, which is easier to plan early than to do under launch pressure.

This is not an argument against modern navigation. It is an argument for testing the app that exists, not the one the checklist was written for.

Impact box

What to test

Testing starts from how the app actually navigates, not from its manifest. At a high level, three areas.

• Route authorization invariants. For every sensitive route, what must be true before it is shown, and is that enforced in state and logic rather than only in what the UI offers? Check that the invariant still holds when the route is reached in an unusual order.

• State serialization and logging exposure. Follow what navigation state contains, where it is saved, and which logs, crash reports and analytics events can see it.

• Replay and restore behaviors. Check what happens after process death, after sign-out, after an account switch, and where relevant through deep links. Restored state should be re-validated, not trusted.

For fixes, the heuristics are short. Pass identifiers through navigation state and load sensitive data from a source that checks authorization. Enforce route requirements where the decision is made, not only where the screen renders. Clear or invalidate navigation state when the session changes. And treat anything that serializes state as an output channel.

What to ask a vendor

Two questions separate shallow testing from the real thing. A third covers how findings are backed up.

Good answers are specific about flows, sessions and evidence. Vague answers about “full coverage” are worth a follow-up.

Where to start

If you want a fast, high-signal view, start with the Security Health Check. It focuses on the few flows that matter most before your next milestone, including where sensitive state may be exposed, and gives your team a prioritized plan to ship and verify.

Have a question about your product? Leave your email and we’ll get in touch within 1–2 business days.