Skip to content

MASWE-0054: Device Attestation Not Implemented

MAS Requirement

The app implements device attestation.

Mappings

MASVS V1: MSTG-RESILIENCE-10

MASVS V2: MASVS-RESILIENCE-1

Overview

This weakness occurs when an app does not implement device attestation, so its backend cannot distinguish requests made from genuine, uncompromised devices from those coming from rooted, emulated, tampered, or automated environments.

Device attestation uses platform services, such as the standard Android hardware attestation API, the Play Integrity API or iOS DeviceCheck and App Attest, to provide the backend with cryptographically verifiable evidence about the device associated with a request. The evidence and security properties differ by platform and service. Without device attestation, the backend cannot independently verify device-origin claims made by the client. The backend must validate attestation evidence and apply the service-specific request-binding, freshness, and replay protections; client-side evaluation is another bypassable local check.

On Android, both the hardware-backed attestation and Play Integrity APIs can provide server-verifiable assurance that the device has not been compromised in ways covered by its device-integrity verdicts or signals, such as an unlocked bootloader, an unrecognized operating-system image or an outdated security patch level. Their main differences include:

  • Google Mobile Services (GMS) Requirement: Direct hardware-backed key attestation uses Android Keystore and does not require Google Play services on the device to request an attestation. Play Integrity depends on Google Play components and Google services.
  • Verdict Generation and Policy Enforcement: With direct key attestation, the backend receives signed properties and defines which boot states, operating-system signing keys, patch levels, and application identities it accepts. Play Integrity evaluates the available signals and returns Google-defined verdict labels. In both cases, the developer decides how the backend responds.

On iOS, DeviceCheck and App Attest do not provide equivalent assurance about operating-system compromise. They can establish that evidence originates from genuine Apple hardware; App Attest also binds that evidence to a legitimate app instance, but neither service attests the integrity of iOS.

Modes of Introduction

  • No Attestation Integrated: Not using the platform's attestation services at all, leaving the backend with no device-integrity signal.
  • Client-Side-Only Verification: Requesting attestation but evaluating the verdict in the app instead of verifying it server-side.
  • Missing Freshness Guarantees: Verifying attestation without a server-issued nonce or timeliness check, allowing verdicts to be replayed.
  • Verdicts Not Enforced: Collecting attestation results but not gating sensitive operations on them.
  • Incomplete Evidence Validation: Accepting device-attestation evidence without applying the service-specific checks for request binding, replay protection, and the device claims required by the backend's policy.

Impact

  • Compromise of System Integrity and Business Operations: Attackers can drive the backend with automated or tampered clients, resulting in fraud, scraping, fake accounts, and abuse of the app owner's services.
  • Bypass of Protection Mechanisms: Attackers can leverage tampered running environments to bypass the app's security checks or feature restrictions, resulting in unauthorized access to protected app functionality.
  • Financial Loss: Attackers can abuse promotions, premium features, or transaction flows from unattested environments, resulting in direct monetary loss to the app owner.

Mitigations

  • Integrate Platform Attestation: Validate the rootOfTrust fields from the key attestation extension or use Play Integrity API and iOS DeviceCheck / App Attest to obtain device- and app-integrity verdicts.
  • Verify Server-Side with Freshness: Have the backend verify attestation tokens cryptographically, bind them to a server-issued nonce, and check timeliness before trusting them.
  • Gate Sensitive Operations on Verdicts: Require valid attestation for high-risk API calls and degrade or deny service to unattested clients.
  • Layer with Local Checks: Combine attestation with local environment checks (see Root/Jailbreak Detection Not Implemented, Emulated or Virtual Device Detection Not Implemented) for defense in depth, and assess the overall scheme against known bypasses.

Tests

No Tests Yet

The MASTG doesn't contain any tests for this weakness yet. If you have proposals or would like to work on some, please open an issue in https://github.com/OWASP/mastg/issues indicating the MASWE-0054 mapping, the test titles and a summary of the tests.