Offline capability is a product requirement before it is a security problem. A field technician in a basement, a ticket scanner at a venue with no signal, an identity card presented where there is no connectivity — the product has to work.
Making it work means moving a decision from your server to a device an attacker may own. Every finding in this class follows from that single change.
The three questions
For any offline feature, an assessment asks:
- What is stored on the device to make the decision?
- What decides, and can the decision be changed?
- What happens when it reconnects?
The third is the one most often under-tested and most often where the serious finding is.
What is stored
Offline operation requires local data — cached credentials, a token valid without a network round trip, a downloaded record set, cryptographic material for validating something presented to it.
The testing is the standard storage surface with a sharper edge, because the stored item is now security-relevant by design rather than incidentally. On Android: SharedPreferences, SQLite and Room, internal and external storage, and what survives adb backup. On iOS: the Keychain and its accessibility class, Core Data, cached responses, and whether ThisDeviceOnly was applied.
The specific question worth asking: how long does offline material remain valid? A cached credential with a long or absent expiry is a credential that outlives the session it belonged to.
What decides
If the app determines offline whether something is valid, that determination happens in code an attacker can instrument.
The weak pattern is a local function returning a boolean which the application then acts on. Under Frida or Objection that boolean is flipped in a line of script. Root or jailbreak detection wrapped around it raises cost and does not change the outcome.
The stronger pattern is cryptographic. The thing being validated carries a signature the device verifies against a public key, and the device cannot forge a new one because it does not hold the private key. The decision is still made locally, but forging a valid input requires the signing key rather than a debugger.
That distinction — between a decision that can be flipped and an artefact that must be forged — is usually the single most consequential design question in an offline feature.
What happens on reconnect
Here is where we find the findings that matter, and where testing is most often thin.
- Is offline-captured data validated server-side on sync, or trusted because it was already accepted locally? An application that accepts locally-validated results without re-checking them has moved its authorisation boundary onto the handset permanently.
- Can offline events be back-dated? If the record carries a device-supplied timestamp, that timestamp is attacker-controlled. An action can be made to appear to have happened before a revocation.
- Can offline events be replayed? Without idempotency, the same captured event submits repeatedly.
- What happens to revocations issued while the device was offline? The window between revocation and sync is a real exposure, and it should be a documented, bounded decision rather than an accident.
- Is there conflict resolution, and can it be steered? Where server and device disagree, whoever wins is making a security decision.
The design conversation
The useful output of testing an offline feature is rarely a list of bugs. It is a clear statement of what the offline mode assumes, how long those assumptions hold, and what an attacker with a device in hand can actually achieve.
Most teams have made these trade-offs implicitly. Writing them down — offline validity window, what is signed and what is merely stored, what is re-validated on sync, how revocation propagates — usually improves the design more than fixing any individual finding does.