Mobile Security

One assumption governs this entire lesson: you do not control the device your app runs on. Everything else follows from it, and a team that internalises that sentence makes better decisions than one that memorises a checklist.

Be specific about what it means. The device may be lost or stolen. It may be handed to a colleague, a family member or a site contact for a perfectly innocent reason. It may be rooted or jailbroken, which is to say the operating system's own protections have been removed by whoever owns it. Its network may not be one you would choose. And your app is a file that anybody can download, so the code and the resources inside it can be read by anybody who wants to read them. None of these is exotic. Over a fleet of a few hundred field devices, all of them happen.

From that follows the one rule to take away if you take nothing else: never embed a secret or an API key in the app. Not in source code, not in a configuration file, not in a resource, not in an environment variable baked in at build time, and not in an encrypted blob the app decrypts at startup — because the key that decrypts it has to ship too. Obfuscation is the same shape of argument: it raises the effort required and changes nothing about the outcome. An app is distributed to everybody, so anything inside it is distributed to everybody. An embedded key is a published key.

The consequence is architectural rather than a coding detail. Anything privileged happens on your server. If the field app needs a third-party mapping service, your server holds that provider's key and the app calls your server. If the app needs to send email, your server sends it. And if a piece of logic must not be altered by whoever holds the device — what a user may see, whether a visit can be closed — that logic lives on the server and the app displays the answer. This also improves things that have nothing to do with security: one copy of a provider key can be rotated without a release, rate-limited per user, and replaced with a different provider without stranding the app versions already in the field.

The lesson is defensive throughout. The goal is that a device leaving its owner's hands is a contained problem: the data on it is limited, the credentials on it can be revoked, and nothing on it grants access to anything beyond that one user's own work. Nothing here describes how to attack a device or get around a protection, and you do not need that to build well.

/** Everything the client is allowed to know. This ships to every user. */
export interface ClientConfig {
  apiBaseUrl: string;
  requestTimeoutMs: number;
  featureFlags: Record<string, boolean>;
}

interface SiteLocation {
  latitude: number;
  longitude: number;
}

/**
 * Looks up a site's coordinates. The mapping provider's key never leaves the
 * server: the app asks the employees API, and the API asks the provider.
 */
export async function siteLocation(
  config: ClientConfig,
  accessToken: string,
  siteCode: string,
): Promise<SiteLocation> {
  const path = "/sites/" + encodeURIComponent(siteCode) + "/location";

  const response = await fetch(config.apiBaseUrl + path, {
    headers: { Authorization: "Bearer " + accessToken },
    signal: AbortSignal.timeout(config.requestTimeoutMs),
  });

  if (!response.ok) throw new Error("Site location unavailable");
  return (await response.json()) as SiteLocation;
}

• The shape is the transferable part. Your toolkit's HTTP client and configuration mechanism will look different; what carries across is the split between what ships and what stays behind.
• ClientConfig contains a base URL, a timeout and some flags. None of those is a secret. A base URL is discoverable from any request the app makes, so treating it as confidential achieves nothing while making the config harder to work with.
• What is absent is the point. There is no mapping provider key here, because the app does not have one. It asks your API for a site's location, and your API — running where you control the environment — calls the provider with the key it holds.
• The Authorization header carries the user's own token from secure storage, as set up in the authentication lesson. That is a per-user credential the server can revoke, which is a categorically different thing from a shared key baked into every installation.
• encodeURIComponent is defensive rather than cosmetic. A site code is data, and data placed into a URL without encoding can change the shape of the request. The same reasoning applies to anything from a deep link, a scanned code or a text field.
• The timeout is here because a request with no deadline is its own availability problem, as the API lesson covered. Security work that leaves the app hanging has not made anybody safer.

const SENSITIVE_FIELDS = new Set([
  "authorization",
  "accesstoken",
  "refreshtoken",
  "password",
  "dateofbirth",
  "nationalinsurancenumber",
  "homeaddress",
]);

function normalise(key: string): string {
  return key.toLowerCase().replace(/[-_\s]/g, "");
}

export function redact(value: unknown): unknown {
  if (Array.isArray(value)) return value.map(redact);

  if (value !== null && typeof value === "object") {
    const output: Record<string, unknown> = {};
    for (const [key, inner] of Object.entries(value as Record<string, unknown>)) {
      output[key] = SENSITIVE_FIELDS.has(normalise(key)) ? "[redacted]" : redact(inner);
    }
    return output;
  }

  return value;
}

/** The only logging entry point the app uses. */
export function logEvent(name: string, detail: Record<string, unknown>): void {
  console.log(name, redact(detail));
}

• Treat this as a shape. Whatever logging or crash reporting library you use, the principle is that one function is the entry point and redaction happens inside it, before the value goes anywhere.
• Redaction has to be at the point of writing. A log line already sent to a crash reporting service is in somebody else's storage, on their retention schedule, and deleting the code that produced it changes nothing about the copy they hold.
• normalise exists because field names are inconsistent in real payloads. Without it, refresh_token and refreshToken are different strings and one of them slips through — which is the kind of gap that is invisible in review.
• The honest weakness of this approach is that it is a denylist. It protects the fields somebody remembered, and a new field added next month is logged in full until somebody notices. For anything holding personal data, choosing the specific fields you log is stronger than listing the ones you will hide.
• Never log a whole request or response object, and be careful with HTTP client logging middleware — several clients capture headers by default, which means the Authorization header, which means the user's token in a log file.
• One more habit that costs nothing: turn verbose logging off in release builds. Debug logging that is useful on your desk becomes a description of your app's internals sitting on a device you do not control.