Expo app attestation becomes a backend control for mobile API trust

At a glance

What this is: This is a guide to adding mobile app attestation to Expo React Native apps so backend APIs can verify that requests came from a genuine, trusted app instance.

Why it matters: It matters because mobile API security cannot rely on user authentication and TLS alone when bots, emulators, and modified builds can still reach sensitive backend logic.

Context

Expo development builds give React Native teams a way to add native modules, but they also create a security decision point: backend APIs need a reliable way to distinguish a real app from an altered client. In mobile environments, transport security protects the channel, not the caller, so request provenance remains a separate control problem.

This article is about app attestation as a backend trust signal for mobile API traffic. It sits alongside authentication, authorisation, and server-side validation rather than replacing them, and that distinction matters for any team protecting API domains exposed through an Expo app.

Key questions

Q: How should teams secure mobile APIs when client integrity cannot be trusted by default?

A: Use authentication to identify the user, then add a separate client-integrity check before sensitive requests are accepted. Backend verification should confirm that the request came from an approved app instance, not just any client that can speak the API. That makes replay, automation, and repackaging harder to abuse, especially for mobile workloads that expose business-critical functions.

Q: Why do mobile apps need attestation before API access is granted?

A: Because the application runtime is no longer trustworthy by default. Attestation gives the API a way to distinguish a real, untampered app instance from a modified client or automated replay tool, which is essential when the device itself can no longer be assumed safe.

Q: What are the signs that a mobile API security design is too weak?

A: A weak design usually shows up when teams rely on API keys for more than basic tracking, send sensitive data without HTTPS and TLS, or treat tokens as if they were proof of trust without verifying the claims they carry. These gaps leave identity, data protection, and authorisation decisions underspecified.

Q: Should mobile teams keep API keys inside the app or deliver them at runtime?

A: Runtime delivery is safer when the secret must exist on the client at all, because the backend can restrict access to attested app instances. Embedding keys in the app increases the chance of extraction, reuse, and abuse across distributed copies of the client. The stronger pattern is to minimise static secrets and make the backend the trust decision point.

Technical breakdown

How mobile app attestation changes API trust decisions

Mobile app attestation gives the backend a way to verify that an API request came from an approved application instance, not merely from a device or a logged-in user. In this pattern, the app receives a short-lived signed token, the backend validates it, and only then allows the request to reach protected logic. The security value is in binding request acceptance to app integrity and runtime context. Without that binding, any client that can speak the API protocol can attempt to exercise sensitive functionality, including scripts, emulators, and repackaged builds. See the API Security Buyer's Guide.

Practical implication: Treat attestation as a request admission control and enforce verification before sensitive business logic executes.

Why Expo development builds matter for native security controls

Expo Go is convenient for development, but it cannot host arbitrary native modules, which means security tools that rely on native runtime hooks need a development build instead. A development build gives the app its own native runtime and allows native libraries to be bundled into the installed client. That matters because app attestation, secret handling, and other runtime protections often depend on code that must execute inside the app rather than in JavaScript alone. For security teams, the build model becomes part of the control boundary, not just an engineering preference. See the Secure Software Development Lifecycle (SSDLC) Guide.

Practical implication: Move security-sensitive Expo work into a development build workflow before you attempt to add attestation or runtime secret controls.

How backend verification and runtime secrets protection fit together

Attestation only becomes a control when the backend verifies the token and rejects requests that fail the trust check. The same pattern can be extended to secrets delivery, where API keys and third-party credentials are not embedded in app code but delivered at runtime only to attested clients. That reduces exposure from static secrets sitting in JavaScript bundles or configuration surfaces that can be inspected. The architectural point is that the app is not trusted to hold secrets simply because it is installed on a device; the backend decides whether the client qualifies for sensitive material. See the API Key Management Guide.

Practical implication: Verify attestation server-side and keep reusable secrets out of app code wherever runtime delivery is possible.

Threat narrative

Attacker objective: The objective is to access backend API functionality and secrets without proving the request came from the genuine app.

1. Entry occurs when an attacker targets the exposed mobile API using a bot, emulator, modified build, or scripted client rather than the legitimate Expo app.
2. Credential_harvested occurs when the attacker reuses static API keys or abuses requests that the backend cannot distinguish from genuine app traffic.
3. Escalation occurs when the untrusted client reaches protected API domains and exercises sensitive business logic without an attestation gate.
4. Impact is unauthorised API abuse, replay, or credential exposure that bypasses the intended mobile trust model.

Breaches seen in the wild

• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

App attestation is a request provenance control, not an identity control. The core problem in mobile API security is not whether a user can authenticate, but whether the backend can trust the client generating the request. That is why attestation belongs in the admission path before sensitive logic, while user authentication and authorisation remain separate decisions. Practitioners should treat the control as a proof-of-client-integrity layer, not as a substitute for IAM.

Expo’s build model becomes part of the security boundary once native controls are required. Development builds are not just an implementation detail, because native attestation and secret-handling controls need code that executes inside the installed app. If teams stay in a packaging model that cannot support those controls, they leave the backend with no trustworthy signal about client integrity. The operational implication is that build strategy and control strategy have to be designed together.

Static secrets in mobile apps are a lifecycle failure, not just a storage failure. When app config can expose runtime values, the issue is not simply where a secret is stored but whether it is ever shipped in a form that can be reused outside an attested runtime. That is a classic NHI and API governance problem because API keys and service tokens are machine credentials, not user credentials, and they need issuance and delivery rules that match that reality.

Approov’s model underscores the shift from trusting endpoints to trusting runtime state. Mobile teams can no longer assume that a signed app package is enough to establish API trust, especially when replay, automation, and repackaging are realistic attack paths. The control question moves from who the user is to whether the caller is the intended application instance. Practitioners should design backend acceptance rules around runtime proof, not app distribution alone.

Secret leakage through mobile distribution channels remains one of the easiest ways to widen attack surface. Once a credential sits in client code, every copy of the app becomes a potential disclosure point, even before any API call is made. That is why runtime delivery, rotation discipline, and backend enforcement need to be coupled. The practitioner takeaway is to treat mobile secrets as governed machine identities, not embedded application constants.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: API Key Management Guide

What this signals

Request provenance is becoming a first-class mobile control. As mobile APIs become easier to automate, the decisive question is no longer whether the caller has a valid user session, but whether the backend can trust the runtime that produced the request. That shifts control design toward attestation, token validation, and secrets delivery rules that assume client-side compromise is normal.

Mobile secrets should be treated as governed machine credentials. When API keys or third-party tokens are embedded in app code, they behave like long-lived reusable credentials that can be copied far beyond the intended runtime. The better operating model is to couple attestation with governed issuance, because secret exposure in mobile distribution channels is a lifecycle problem as much as a storage problem.

Secrets management gaps remain common in developer workflows. Only 44% of developers are reported to follow security best practices for secrets management, according to the State of Secrets in AppSec, which helps explain why mobile apps still leak credentials into code and config. For practitioners, the programme implication is clear: secret governance must move into build, runtime, and backend enforcement together.

For practitioners

• Enforce backend verification for every attested request Reject protected API calls unless the server validates the attestation token before any sensitive business logic runs.
• Move mobile builds to a development workflow Use an Expo development build when the app needs native security controls, because Expo Go cannot host them.
• Remove reusable secrets from app code Do not embed API keys, third-party credentials, or other reusable secrets in app config or JavaScript bundles.
• Scope attestation to protected API domains Apply the control to the API routes that actually need extra trust, then measure which endpoints still accept unauthenticated or unverified clients.

Key takeaways

• Mobile API trust depends on more than user authentication, because unmodified apps, emulators, and scripted clients can all reach the same backend surface.
• The control works by validating a short-lived attestation token on the server before protected requests proceed into sensitive logic.
• Teams that still ship reusable secrets in app code need to treat that as a lifecycle and governance failure, not just a packaging mistake.

Related NHI Mgmt Group resources: API Security Buyer's Guide · API Key Management Guide · API Security Guide · Secure Software Development Lifecycle (SSDLC) Guide

Key terms

• App Attestation: App attestation is a trust decision that checks whether a mobile app and its device environment meet policy before sensitive actions are allowed. It can use device integrity, app integrity, and telemetry to decide whether requests should be trusted, restricted, or denied.
• Development Build: A development build is an Expo app package that includes its own native runtime and can host custom native modules. Security teams need it when controls depend on code that cannot run inside Expo Go, such as attestation, native secret handling, or other runtime protection libraries.
• Runtime Secrets Protection: Runtime secrets protection means credentials are delivered only when the application and session context have been verified. It reduces the value of reverse engineering because the secret is not permanently embedded in the binary or left exposed on the device.
• Access Provenance: Access provenance is the record of how an identity was created, approved, used, and withdrawn. In NHI governance, it is the evidence trail that lets teams prove an account is legitimate, explainable, and still within its intended access boundary.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security outcomes their programmes depend on.