Mobile API trust gaps demand RASP and attestation together

At a glance

What this is: Guardsquare says mobile API attacks increasingly ride on apparently legitimate app traffic, so servers need both client hardening and cryptographic attestation to decide whether requests are trustworthy.

Why it matters: IAM and application security teams need to treat mobile app integrity as part of API trust, because authentication alone does not prove the request came from a genuine application instance.

By the numbers:

• Up to 95% of API breaches originate from what appears to be legitimate API traffic, according to Guardsquare.

Context

Mobile API security is really a trust problem: the server can authenticate a user or token, but it cannot automatically verify that the request came from an untampered app running in a trustworthy environment. That gap matters because mobile apps now front banking, commerce, and enterprise workflows, which makes the request path itself a security control surface.

The article focuses on two linked controls. RASP helps harden the app and expose tampering, while attestation gives the backend a cryptographic verdict about the app and device context. For identity and access teams, the relevance is clear: the weakest point is no longer only authentication, but the integrity of the client that presents it.

Key questions

Q: What breaks when mobile apps trust attestation responses without backend correlation?

A: The app loses the ability to tell whether the response came from the requesting device or from a proxy device. That makes spoofed trust states look legitimate, which can undermine fraud controls, access decisions, and compliance checks.

Q: Why does client hardening reduce mobile API risk?

A: Client hardening makes it harder for attackers to inspect, hook, or repack the app into a useful attack tool. It does not by itself prove trust to the server, but it raises the cost of tampering and improves the quality of any evidence the app reports. That makes downstream attestation far more reliable.

Q: How do security teams decide when to step up mobile API requests?

A: Use the attestation verdict and the request context together. High-confidence requests can proceed, suspicious requests can trigger re-authentication or delay, and low-confidence requests can be blocked or routed to fraud handling. The decision should reflect risk at the transaction level, not just whether the user logged in successfully.

Q: What is the difference between mobile app attestation and API authentication?

A: Authentication confirms that a user or client presented a valid credential. Attestation confirms that the app and device context behind the request meet a trust threshold at the time of the call. In practice, authentication tells you who or what claims access, while attestation tells you whether that claim comes from a trustworthy runtime.

Technical breakdown

Why mobile API trust breaks at the client boundary

A mobile API request can look valid even when it is generated by a repackaged app, a hooked process, or a script that reuses stolen parameters. The server sees the request payload and the presented credentials, but not the runtime state of the client that produced them. That is why certificate pinning, login checks, and static app controls are not enough on their own. The security problem is not just whether a user authenticated, but whether the app instance and execution environment are still trustworthy when the API call is made.

Practical implication: Treat client integrity as a prerequisite to API authorisation, not as a separate hardening exercise.

How RASP changes what the app can prove

Runtime Application Self-Protection embeds checks into the mobile app so it can detect debugger attachment, rooting, emulation, hooking, injection, and repackaging while it is running. This does not merely log tampering. It can terminate the app, reset the session, or refuse a request when integrity conditions fail. In practical terms, RASP turns the client into a source of security evidence, but that evidence still needs independent server-side validation before it can be trusted for access decisions.

Practical implication: Use RASP to raise the attacker cost and to generate stronger evidence for downstream trust decisions.

Why attestation is the server-side trust decision

Mobile app attestation is a cryptographic challenge-response process in which the app presents evidence, a dedicated service evaluates it, and the backend verifies a signed short-lived token before allowing access. This matters because the verdict is issued outside the application backend and is tied to the integrity state of the app and device at request time. The result is not just allow or deny. It can support step-up authentication, delay, blocking, or fraud investigation based on the trust verdict.

Practical implication: Move the final trust decision to the server and make API access conditional on a fresh attestation verdict.

Threat narrative

Attacker objective: The attacker wants to use a trusted-looking mobile client to reach backend APIs at scale without triggering the controls that would stop a non-genuine request.

1. Entry occurs when attackers reverse engineer a legitimate mobile app, tamper with it, or use a script that mimics normal traffic.
2. Credential and logic extraction follow as attackers pull API keys, bypass checks, and reuse request parameters at scale.
3. Escalation happens when the attacker uses those credentials or a repackaged client to perform credential stuffing, account takeover, or business-logic abuse.
4. Impact is API fraud, data theft, payment abuse, and large-scale unauthorized access that appears to originate from legitimate traffic.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.

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

Mobile API trust is now a client integrity problem, not just an authentication problem. When a server cannot distinguish a genuine app instance from a tampered or scripted one, normal login controls only confirm who presented the request, not whether the request deserves trust. That shifts the governance question toward evidence quality at the point of issuance. Practitioners should treat client attestation as part of access assurance, not as optional hardening.

RASP and attestation solve different governance failures, and confusing them creates blind spots. RASP improves the trustworthiness of the app's own evidence by making tampering harder and more visible. Attestation gives the backend a cryptographic decision it can enforce regardless of client claims. The combination matters because one control protects evidence generation while the other protects evidence consumption. Security teams should design both into the same trust workflow.

Mobile API abuse is a form of identity abuse in a device-first channel. The article shows how a legitimate user session can be weaponised through a tampered app, stolen parameters, or automated replay, which means the identity signal alone is insufficient. This is where IAM and API security converge: the access decision must account for client integrity, not just token validity. Practitioners should align mobile access governance with request integrity checks.

Strategic delay is a useful control when abuse is probabilistic rather than binary. Not every suspicious request should be blocked immediately if doing so reveals too much to an attacker or disrupts legitimate edge cases. The article's trust-verdict model supports stepped responses, including delay, escalation, and review. That is a better fit for bot-heavy API abuse than static perimeter blocking. Teams should map response levels to risk, not just to success or failure.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• More than 80% of enterprises will have used generative AI APIs or deployed GenAI applications by 2026, up from 5% in 2023, according to Gartner.
• Read next: API Key Management Guide

What this signals

Mobile request integrity is becoming a governance boundary. As app traffic, bot traffic, and scripted abuse converge, teams need to stop treating API protection as a perimeter problem and start treating it as a runtime trust problem. That means tying access decisions to client state, request context, and fraud signals instead of relying on authentication alone.

Trust verdicts create a better operating model than binary allow-or-deny controls. The practical advantage is not just tighter blocking, but more precise containment when risk is uncertain. Security teams should expect attestation-led controls to sit alongside IAM, fraud, and application security workflows, especially where mobile channels carry payments or sensitive account actions.

For practitioners

• Implement mobile app attestation at the API gate Require a fresh attestation token before the backend processes sensitive mobile requests, and make token validation part of the normal authorisation flow.
• Use RASP to harden the client runtime Detect rooting, debugger attachment, hooking, emulation, and repackaging inside the app so tampering produces a security signal before the request leaves the device.
• Apply risk-based responses to attestation verdicts Map high-trust, medium-trust, and low-trust verdicts to allow, step-up authentication, delay, logging, or fraud workflows instead of relying on a single allow-or-block decision.
• Separate API trust from user authentication Review mobile controls to make sure a valid login session does not automatically imply a trusted client, especially for payment, authentication, and data-access endpoints.
• Instrument bot-heavy endpoints first Prioritise attestation on endpoints already exposed to credential stuffing, transaction abuse, or scripted traffic, because those are the highest-value places to break request forgery patterns.

Key takeaways

• Mobile API abuse often succeeds because requests look legitimate even when they come from tampered apps or scripts, which makes client trust the real control gap.
• The strongest defence is a two-part model: RASP hardens the app at runtime, and attestation lets the server verify request trust before granting access.
• Practitioners should align mobile access decisions with runtime evidence, step-up responses, and fraud workflows rather than assuming authentication alone proves trust.

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.
• Runtime Application Self-Protection: RASP is a runtime control that detects and can block suspicious application behaviour as it happens. In NHI contexts, it can contain abuse from service accounts or tokens, but it does not replace identity ownership, entitlement review, rotation, or deprovisioning.
• Request integrity: The property that the security decision, validation result, and executed payload all refer to the same transaction. Without request integrity, an application can appear to enforce safe behaviour while a later stage silently changes what actually runs.
• Trust Verdict: A server-side decision derived from attestation evidence about whether a request, app, or device meets the required trust threshold. It is more useful than a simple pass or fail because it can support different responses such as allow, step-up, delay, or block.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle control. It helps security and IAM practitioners connect trust decisions to the identities and credentials that actually move across modern systems.