Notifications
Clear all
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.
NHIMG editorial — based on content published by Guardsquare: How Server-Side App Attestation Protects APIs From Bot Attacks
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: What breaks when mobile APIs trust the app session without verifying client integrity?
A: Attackers can replay legitimate-looking requests through emulators, tampered apps, or automated clients and use valid credentials to bypass the intended user experience.
Q: Why do bots create a governance problem for mobile identity and access controls?
A: Bots turn valid identity paths into automation channels.
Q: How do security teams know whether app attestation is actually reducing abuse?
A: Look for declines in successful automated logins, lower replayable request volume, fewer anomalous device combinations, and fewer suspicious account-creation patterns after attestation is enforced.
Practitioner guidance
- Define app integrity as an authorization requirement Require a positive attestation verdict before sensitive mobile APIs can complete, especially for account creation, login, money movement, and reservation flows.
- Separate bot detection from bot response Create response tiers for suspicious traffic, including silent monitoring, step-up verification, rate limiting, and controlled denial rather than one fixed block action.
- Instrument API abuse with fraud and IAM telemetry Correlate attestation outcomes with credential stuffing indicators, device signals, transaction anomalies, and account lifecycle events so investigators can see the full pattern.
What's in the full article
Guardsquare's full analysis covers the operational detail this post intentionally leaves for the source:
- Examples of bot attack patterns across credential stuffing, scraping, fake account creation, and reservation abuse
- How server-side attestation verdicts are packaged, evaluated, and updated without a new mobile release
- The policy criteria teams can tune for rooted devices, emulators, and other client trust failures
- Operational response options such as delayed verification, fraud flagging, and security team notification
👉 Read Guardsquare's analysis of server-side app attestation for mobile API bot defense →
Server-side app attestation for mobile APIs: are your controls keeping up?
Explore further
20/08/2026 6:16 pm
Application integrity is now part of identity governance. Mobile security teams have traditionally treated the user session as the trust anchor, but bot operators exploit the fact that the app itself is often unauthenticated. That creates a governance gap between user identity and request provenance. Practitioners should treat app attestation as a policy decision about what software is allowed to speak for the user.
A question worth separating out:
Q: Who is accountable when a mobile app allows bot-driven API abuse?
A: Accountability is shared across application security, IAM, mobile engineering, and fraud operations because the failure sits at the boundary between identity proof, client trust, and API enforcement. The teams that own policy, telemetry, and workflow decisions must jointly define what evidence is required before a request is allowed.
👉 Read our full editorial: Server-side app attestation closes the bot defense gap in mobile APIs
