Topic starter
20/08/2026 5:28 pm
TL;DR: Bots now drive more than half of web traffic, and Guardsquare argues that mobile APIs need server-side app attestation because authentication proves the user, not the application. The governance problem is the missing trust check on client integrity, which leaves credential stuffing, fraud, scraping, and abuse patterns exposed to automation.
Editorial analysis by NHI Mgmt Group, based on content published by Guardsquare: “How Server-Side App Attestation Protects APIs From Bot Attacks”.
Key questions
Q: What fails when mobile APIs trust authentication but not app integrity?
A: When an API trusts the user session but not the client, attackers can replay legitimate-looking requests from a modified app or scripted bot.
Q: Why do bots increase risk in mobile API environments?
A: Bots reduce the cost of abuse and raise its scale.
Q: How can security teams tell whether attestation evidence is still reliable?
A: They should verify three things: the control scope, the expiry date, and whether the evidence actually covers the service or environment being reviewed.
Practitioner guidance
- Deploy server-side attestation at high-value API entry points Start with login, account creation, payment, reservation and scraping-prone endpoints where automated clients can do the most damage.
- Classify the abuse pattern behind each mobile workflow Map each API flow to the bot behaviour it attracts, such as credential stuffing, fake account creation, rewards abuse or data scraping.
- Separate enforcement from the mobile release cycle Keep attestation policy on the server side so you can adjust rooted-device rules, emulator detection and certificate revocation without shipping a new app version.
Bottom line: Mobile API defence breaks down when authentication proves the user but not the application instance making the request.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:16 pm
Client integrity has become a first-class identity control for mobile APIs. Once attackers can copy app behaviour, authentication alone only proves the user authenticated, not that the request originated from a trusted application instance. That shifts the governance problem from session acceptance to request provenance. For IAM and appsec teams, the practical conclusion is that identity assurance now includes the integrity of the calling client.
A few things that frame the scale:
- 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.
A question worth separating out:
Q: What should teams do when a mobile request fails attestation?
A: Treat it as a trust failure, not just a rejection. The response should depend on the flow: block high-risk transactions, challenge suspicious sessions, and send the event to fraud and monitoring teams so they can correlate the failure with account behaviour and wider attack patterns.
👉 Read our full editorial: Server-side app attestation closes the bot defense gap in mobile APIs