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.
Editorial analysis by NHI Mgmt Group, based on content published by Guardsquare: “Bridging the Trust Gap: A Unified Strategy for Mobile API Security”.
By the numbers:
- Up to 95% of API breaches originate from what appears to be legitimate API traffic, according to Guardsquare.
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.
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.
Q: How do security teams decide when to step up mobile API requests?
A: Use the attestation verdict and the request context together.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:29 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Mobile API trust gaps demand RASP and attestation together