Separate the trust questions
| Question | Typical control |
|---|---|
| Who is the user? | Authentication |
| May this user access this object? | Authorization |
| What app/device signals accompany the request? | Attestation or integrity service |
| Is the action being abused? | Rate limits, fraud analysis and business rules |
The Play Integrity overview and Firebase App Check overview describe related but different integrations. App Check can use provider signals to protect supported resources; direct Play Integrity gives a server a verdict to evaluate in its own workflow.
Bind evidence to a useful decision
Choose the action that needs protection and the server-side response to each relevant outcome. Protecting a high-value transaction may require different treatment from reading public content.
Do not reduce the entire threat model to “device passed, allow everything.” A legitimate app can still be operated by an abusive user.
Plan for imperfect environments
Older devices, alternate distribution, temporary provider failures and unsupported configurations can affect the result. Distinguish unavailable evidence from a positive determination of abuse.
Use proportionate responses such as a retry, remediation, reduced-risk flow or additional verification where appropriate. Avoid silently granting privileged access when verification fails.
Keep the final decision off the client
A boolean computed solely inside the APK can be changed or bypassed by a modified client. The backend should validate the provider's evidence and enforce the policy for protected operations.
Do not store a service-account credential or other privileged verifier secret in the app.
Validate with real release paths
Test the actual distributed certificate and package, not only a debug build. Record which signal caused the decision and avoid logging raw tokens.
APKLint's package and Firebase tools can support configuration review. They do not perform live attestation or certify device integrity, so use them to find setup mismatches before validating the complete client-to-server flow.
Protect a coupon claim at the server operation
Suppose an app allows one promotional coupon per eligible account. Attestation can contribute evidence about a request's app or device environment, but the backend still needs to decide whether the account is eligible and whether the coupon was already claimed. A recognized app can send a second request for the same coupon, and a valid user can request another user's resource.
The Play Integrity overview describes using integrity signals within a broader abuse strategy. Define the coupon operation first: authenticated account, coupon identity, eligibility, evidence verification and duplicate prevention. Place the final award after those checks in the server's transaction flow.
Test each reason for refusal independently
Create synthetic cases for a valid eligible claim, an ineligible account, a repeated claim and missing or rejected integrity evidence. Keep the expected outcome explicit. If the ineligible account is refused, identify whether authorization or eligibility caused the refusal; an earlier integration failure should not accidentally make an untested business rule appear correct.
Test provider unavailability as another category. The product may offer a retry or a lower-risk path, but it should not describe unavailable evidence as confirmed abuse or silently grant the protected coupon. Keep ordinary help and account-support access available according to the product's separate access rules.
Observe how the client handles a delayed response after the user changes accounts. Bind the response to the account and operation that requested it. A successful result from the first account must not be displayed as a coupon granted to the second merely because the same screen component is still mounted.
Record a server operation identifier and decision category in the controlled test, excluding raw attestation tokens and private account data. This supports debugging without turning logs into a token archive. Repeat the meaningful cases through the actual distribution path before enforcing the policy broadly.
Keep a separate review for any client-side warning or indicator. Such a label can explain the server's result, but it must not become the source of authority for awarding the coupon. The protected resource should remain governed by the verified evidence and business rules on the server.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
