Client storage, logs, backup and transport trust

Measure where sensitive client state goes, who can retrieve it, and whether transport rejects invalid peers.

Used in these playbooks#

Setup and invariant#

Use a clean owned device or desktop VM with the scoped release, two synthetic accounts, a scoped interception setup, and a unique marker such as BB-CLIENT-01. Define the prospective reader: another ordinary app, another OS user, someone receiving an exported diagnostic bundle, an authorized backup recipient, or a network adversary. A debugger/root reader is a separate model.

Invariant: credentials and private records do not enter a channel readable by an unintended principal, and the release rejects an unauthenticated network peer. Prioritize actual token/data movement; a string called api_key, a backup-enabled manifest, or absent certificate pinning alone is insufficient.

Procedure and command sheet#

1. Record the lifecycle. Start logged out; sign in, perform one marked operation, background/lock, switch accounts, then log out. For each state record relevant preferences, databases, caches, clipboard, notifications and user-exportable diagnostics. Use identity/session for token validity and revocation, and authorization checks for backend effects.

2. Locate only relevant sinks. Search a local source copy and explicitly acquired lab exports. The bounded file-size limit reduces accidental scanning of large databases; use filenames first when output may contain secrets.

rg -n 'Log\.|NSLog|os_log|console\.log|SharedPreferences|UserDefaults' ./source
rg -l --max-filesize 2M 'BB-CLIENT-01' ./lab-export
apkanalyzer manifest print ./app.apk

On Android, inspect allowBackup, fullBackupContent, dataExtractionRules, and the referenced XML. Test the supported restore path using synthetic data. Cloud backups and device transfers can follow different rules; neither follows reliably from one flag across all versions/OEMs. Do not use a legacy adb backup recipe as a universal modern test. Android backup rules.

3. Prove reader access. If the marker appears in logs, show who can obtain that release log under the stated prerequisites. Modern log access is restricted; ADB output does not prove every app can read it. If a diagnostic export includes an owned token, demonstrate the expected exclusion with an otherwise identical export that lacks a session. Share a redacted excerpt and file location, not a full personal log. Android log disclosure.

4. Use a transport control matrix. In a local endpoint or approved test environment, compare a valid certificate, an untrusted issuer, and a wrong-host certificate. Keep request content identical and send only synthetic data. Record the release's exact trust store, endpoint, handshake result and whether an application request is sent. A refusal caused by connectivity is not validation evidence; the valid control must connect. Custom trust code can mistakenly accept invalid chains. Unsafe trust managers.

5. Separate lab changes. A user-installed CA, debug-only trust anchor, disabled trust callback, or instrumentation can make interception intentional. Android debug overrides may bypass pins when their debug CA is used; they are ignored for a non-debuggable build. Therefore verify bad-peer acceptance on the unchanged eligible release before reporting a certificate-validation defect. Network security configuration.

Evidence, decisions and cleanup#

Retain state before/after, sensitivity, exact reader privileges, minimum exposed marker, and reproducible impact. Intended account-owner backup access and approved offline storage are not automatically vulnerabilities. Use file boundaries when exposure depends on permissions or export paths.

• Compare account A, account B, and logged-out state.
• Demonstrate the reader without granting extra privileges.
• Distinguish missing pinning from accepting invalid certificates.
• Remove test CAs/proxies, delete synthetic exports, clear test clipboard values, revoke owned sessions, and restore the lab snapshot.

Privacy surfaces and metadata-only leakage#

Add a reader-specific matrix instead of reporting absent UI flags. Seed one private message BB-PRIVATE-VIEW and a public title. Compare unlocked/locked, foreground/background and A/B account-switch states. Inspect the app switcher snapshot, lock-screen notification preview, clipboard, accessibility text and a diagnostic export through supported OS interfaces. Record the precise reader privileges, user settings and platform version. A photograph taken by an already authorized user or access after explicitly granting a privileged accessibility service is a different threat model. MASVS-STORAGE-2 covers unintended sensitive-data leakage; product guarantees and eligibility determine the report. OWASP storage leakage control.

For analytics/telemetry, place a synthetic marker in a private field and inspect only the lab app's own traffic or configured local sink. Compare the documented consent states and identify the receiving component and fields. Do not test the analytics vendor. A tracking SDK or a privacy-label mismatch alone does not demonstrate the claimed access boundary. OWASP privacy minimization.

For a timing/size/existence hypothesis, first implement it locally using a small blinded set of synthetic present/absent records. Randomize order, keep request sizes and authentication equal, retain every sample, and evaluate the prediction on held-out fixtures. Show what private fact is inferable, from which observable, with what error rate. Ordinary latency variation, a single paired sample and a marker already supplied in the query establish no disclosure. This is an experimental design to investigate a suspected side channel, not evidence that one exists.

• Private content is actually available to the stated unintended reader.
• User consent, OS grants and already-delivered copies are accounted for.
• A metadata-only claim reports false positives and fresh validation cases.
• Remove notifications, clipboard markers, exports and synthetic analytics data.

Vulnerability reverse references#

• Keychain accessibility violates the intended lock boundary — A sensitive item or protected key operation is available in a device state that the application’s security policy requires it to deny.
• Local authentication does not gate the protected operation — A local PIN or biometric screen is bypassed through another reachable path while the supposedly protected data/key operation remains usable.
• Backup or transfer exposes unintended sensitive client state — A supported backup, migration or diagnostic-copy path carries a secret into an unintended recipient or security context.
• Sensitive client state leaks through accessible diagnostics — Logs, crash reports or user-exportable diagnostics disclose a secret or private record to a principal outside its intended audience.
• TLS peer certificate or hostname verification failure — Release trust validation accepts an untrusted certificate chain or wrong-host identity on a sensitive connection.
• Password storage without an adequate adaptive hash — A password verifier has insufficient computational cost for its supported threat model.
• Private client content leaks through a lower-trust display or sharing channel — A private marker appears in a notification, background snapshot, clipboard or another user-visible channel outside its promised audience.

Nearby shared procedures#

Object, function, and property authorization · Authentication, recovery, federation, and session lifecycle · Trace input into queries, commands, and templates · Server-side fetching and network trust boundaries · Browser execution, cross-origin reads, and forged actions · Uploads, downloads, paths, archives, and XML · Workflow invariants, replay, idempotency, and races · REST, GraphQL, gRPC, WebSocket, and SSE permission parity