Notifications
Clear all
Topic starter
19/08/2026 3:52 pm
TL;DR: Mobile APIs are increasingly abused through traffic that looks legitimate, with industry estimates saying up to 95% of API breaches originate from apparent normal requests, according to Guardsquare. The practical lesson is that client hardening alone is not enough, because servers need cryptographic proof that the app, device, and request context are trustworthy.
NHIMG editorial — based on content published by Guardsquare: Bridging the Trust Gap: A Unified Strategy for Mobile API Security
By the numbers:
- 44% of advanced bot activity now specifically targets APIs.
Questions worth separating out
Q: How should security teams handle trust assumptions for mobile API requests?
A: Security teams should stop assuming that a successful login proves the request is trustworthy.
Q: Why do tampered mobile apps increase account takeover risk?
A: Tampered apps let attackers reuse genuine credentials inside a modified runtime that bypasses local controls and exposes secrets or logic.
Q: What breaks when mobile app attestation is missing?
A: Without attestation, the backend has no reliable way to distinguish a genuine app from a repackaged client, script, or bot.
Practitioner guidance
- Map high-risk mobile API actions Identify the API calls that can trigger account takeover, payment movement, profile changes, or sensitive data access, then require stronger trust checks only for those transactions.
- Require server-side attestation for sensitive flows Use attestation verdicts to gate login, credential reset, payment submission, and other privileged actions, rather than relying on client claims or device labels alone.
- Pair RASP with response policy Configure the app to collect integrity evidence, but let the backend decide whether to allow, delay, challenge, or block the request based on policy.
What's in the full article
Guardsquare's full blog post covers the implementation detail this analysis intentionally leaves for the source:
- Runtime policy examples for when RASP should terminate, delay, or continue execution in response to integrity failures
- Attestation workflow specifics, including how short-lived tokens are generated, signed, and verified by the backend
- Operational guidance for combining mobile trust decisions with fraud escalation and step-up authentication
- Examples of how to tune response policy for bots, tampered apps, and suspicious but not fully blocked sessions
👉 Read Guardsquare's analysis of RASP and app attestation for mobile API security →
Mobile API security: are RASP and attestation enough to close trust gaps?
Explore further
19/08/2026 4:29 pm
Mobile API trust gap is now an identity governance problem, not just an app hardening problem. The article is right to frame the issue as a mismatch between what the server can verify and what the client can prove. In modern mobile workflows, the request itself becomes an access event, which means identity, fraud, and application security teams all have a stake in the trust decision. Practitioners should treat request provenance as part of the access model.
A question worth separating out:
Q: How can organisations decide when to challenge or block mobile API traffic?
A: Use the sensitivity of the action and the confidence of the trust signal. Low-risk actions can proceed with normal monitoring, but high-value operations should trigger attestation, step-up authentication, throttling, or denial when runtime evidence looks suspicious. The goal is to protect the action, not just the session.
👉 Read our full editorial: Mobile API trust gaps demand RASP and attestation together
