Protecting your app from unauthorized use is an important part of maintaining a healthy business on the Meta Horizon Store. Meta provides several tools to help you verify that your app is running on a genuine device, that it has not been tampered with, and that the user is entitled to use it. This page describes a layered defense strategy that combines these tools for the strongest protection.

Why app protection matters

Unauthorized distribution of your app can reduce your revenue, undermine user trust, and expose users to tampered versions that may not work as intended. By implementing the protections described on this page, you can:

Verify that your app binary has not been modified

Confirm that your app is running on a genuine Meta Quest device

Check that the user has legitimately obtained your app

Respond appropriately when any of these checks fail

Layered defense strategy

No single protection mechanism is sufficient on its own. The most effective approach combines multiple layers, each addressing a different type of threat. The following table summarizes the available protections and when to use each one.

Layer	Tool	What it verifies	Requires server?	Requires internet?
1	Entitlement Check	User has a legitimate copy of your app	No	No
2	Attestation API	App binary is genuine and device is unmodified	Yes	Yes
3	Server-side validation	Sensitive operations are verified on your server, not the client	Yes	Yes

Note: The links above point to the Unity documentation. Equivalent pages are available for Unreal, Native, Meta Spatial SDK, and Android.

Entitlement check

The entitlement check verifies that the user has legitimately obtained your app through the Meta Horizon Store. It runs locally on the device and does not require an internet connection, making it the fastest and simplest check to implement. You should perform the entitlement check within 10 seconds of the user launching your app.

However, because the entitlement check runs entirely on the client, it can be bypassed by a modified app binary. For this reason, use it as your first line of defense, but do not rely on it as your only protection.

For implementation details, see Entitlement Check.

Attestation API

The Attestation API provides a stronger level of protection by verifying two things:

Genuine app binary: Your app has not been modified or repackaged

Genuine Meta device: Your app is running on an unmodified Meta Quest headset

Unlike the entitlement check, the Attestation API uses a server-side verification flow. Your app requests an attestation token from Meta’s Attestation Server, then sends that token to your own application server for validation. Because the verification happens server-side, it cannot be bypassed by modifying the client app.

The Attestation API requires a Wi-Fi connection and an application server that you host. For implementation details, see Attestation API.

Server-side validation

For apps with online features, move sensitive operations to your server whenever possible. When your server controls access to game content, multiplayer features, or in-app purchases, a tampered client cannot bypass these controls. Use the Attestation API token to gate server-side operations so that only verified clients receive access.

Attestation API best practices

Follow these best practices when integrating the Attestation API to maximize its effectiveness.

Validate tokens on your server only

Never validate attestation tokens on the client side. A tampered app can be modified to skip or fake client-side validation. Always send the token to your application server and validate it there by making a token verification request to Meta’s Attestation Server.

Generate unique challenge values

The challenge_nonce is a critical security component that prevents replay attacks. Follow these guidelines:

Generate each challenge_nonce on your server using a cryptographically secure random number generator

Never reuse a challenge_nonce — generate a new one for each attestation request

Include a unique element tied to the specific operation (such as a transaction ID or session ID) to bind the attestation to a particular action

Ensure the challenge_nonce length is between 22 and 172 characters

Validate all token claims

When your server receives an attestation token, validate the following claims:

Expiration (exp): Tokens are valid for 24 hours. Reject expired tokens.

Nonce match: The nonce in the token must match the one your server generated. Reject mismatches.

Timestamp: Verify the token was generated recently. Reject tokens with timestamps that are too old for your use case.

Package name: Confirm the token was generated by your app’s package name, not a different app.

Certificate hash: Verify the signing certificate matches your app’s expected certificate.

Device integrity: Check the device integrity level. The API returns either “Basic” or “Advanced” integrity levels.

Handle errors securely

Design your error handling to fail securely:

If the Attestation API call fails due to network issues, retry with increasing delays between attempts

If retries continue to fail, treat the session as unverified and limit access to sensitive features

Never assume that a failed API call means the user is legitimate — treat persistent failures as a signal that something may be wrong

Respond with proportional actions

Rather than immediately blocking a user when a check fails, consider a range of responses:

Limit access: Restrict access to online features or premium content

Delay responses: Add delays to server responses for unverified clients

Prompt re-verification: Ask the user to reconnect to Wi-Fi and retry

Log the event: Record the failure for your own analytics without disrupting the user experience

This approach reduces the risk of false positives affecting legitimate users while still protecting your app.

Getting started

If you have not implemented any app protection, start with these steps:

Add an entitlement check — This is the simplest protection to implement and does not require a server. See Entitlement Check for your engine.

Set up the Attestation API — If you have an application server, integrate the Attestation API for stronger protection. See Attestation API for your engine.

Move sensitive logic server-side — For apps with online features, gate access to content and multiplayer behind server-side attestation validation.

For apps without an application server, such as single-player games, the entitlement check provides a baseline level of protection. Consider adding server-side validation if your app generates significant revenue or handles in-app purchases.

Security overview — overview of security features on the Meta Horizon platform

Attestation API — full API reference and integration guide

Entitlement Check — verify user entitlement at app launch

VRC.Quest.Security.1 — security requirement for Meta Horizon Store apps

Data security best practices — securing your app’s data and infrastructure

Protecting your app from unauthorized use