Use this skill when hardening a RevenueCat integration on Android. Covers Trusted Entitlements response verification (INFORMATIONAL, the default since SDK 8.11.0), why the server is always the authority, API key hygiene (public SDK key vs secret REST key), anonymous user identity, and purchase token protections RevenueCat provides automatically.
77%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
Fix and improve this skill with Tessl
tessl review fix ./revenuecat-play-billing/skills/rc-security/SKILL.mdTell the user: "I will review your RevenueCat security posture on Android: verification mode, API keys, user identity, and server side access decisions."
Confirm what RevenueCat already covers so you can focus on the real gaps.
| Concern | Who handles it | How |
|---|---|---|
| Receipt validation against Google Play | RevenueCat backend | Runs before awaitPurchase() returns |
| Purchase token reuse | RevenueCat backend | Tokens are deduplicated server side |
| Fabricated purchase tokens | RevenueCat backend | Fails Google Play verification, no entitlement granted |
| HTTPS transport to RevenueCat | SDK | Always on |
| Retry of token post on network failure | SDK | Retries on next app launch |
Ask the project these questions:
EntitlementVerificationMode explicitly set to DISABLED? (The default since SDK 8.11.0 is INFORMATIONAL.) Does the app read customerInfo.entitlements.verification and act on FAILED?goog_) or has someone accidentally pasted the secret key into the client?Purchases.logIn(yourUserId), or is the app still relying on anonymous $RCAnonymousID:...?Decide each of the following before changing code.
| Mode | Failed verification does what | Pick when |
|---|---|---|
DISABLED | No signing happens | Only if you explicitly opt out |
INFORMATIONAL (default since SDK 8.11.0) | Logged in verification, access still granted | Act on VerificationResult.FAILED yourself if you need to deny access |
SDK 10.x has no enforced mode; see 3.1 below for gating on the result yourself.
Even with Trusted Entitlements (INFORMATIONAL), the client is not the authority for paid content. Decide whether each premium endpoint:
rc-webhooks).Option 2 is cheaper at request time, option 1 has no cache staleness. Pick one, document it, do not mix per endpoint without a reason.
If the app is in production, plan to call Purchases.logIn("your_user_id") with your own authenticated user id. Anonymous ids are device scoped identifiers, not credentials, and are shared across users of the same device.
Add the mode to PurchasesConfiguration:
PurchasesConfiguration.Builder(context, apiKey)
.entitlementVerificationMode(EntitlementVerificationMode.INFORMATIONAL)
.build()Read the verification result when you inspect entitlements:
when (customerInfo.entitlements.verification) {
VerificationResult.VERIFIED -> { /* response is authentic */ }
VerificationResult.FAILED -> { /* possible tampering, log and alert */ }
VerificationResult.NOT_REQUESTED -> { /* verification disabled */ }
VerificationResult.VERIFIED_ON_DEVICE -> { /* verified locally */ }
}SDK 10.x has no enforced mode: FAILED is informational and never blocks access by itself. To enforce, gate on the result yourself:
val trusted = customerInfo.entitlements.verification != VerificationResult.FAILED
val hasPro = trusted && customerInfo.entitlements["pro"]?.isActive == true| Key | Where it lives | What it can do |
|---|---|---|
Public Android SDK key (goog_...) | Embedded in the app binary | Read and purchase for the calling user only |
| Secret REST API key | Your server, secret manager or env var | Full REST API, admin operations, grant entitlements |
In Android code, only the public key appears:
Purchases.configure(
PurchasesConfiguration.Builder(context, "goog_PUBLIC_android_sdk_key").build()
)Never commit the secret key to the app repo. Grep the Android source tree for the secret key prefix and confirm zero hits before release.
Call logIn as soon as you have an authenticated user id:
val result = Purchases.sharedInstance.awaitLogIn("your_user_id")
val customerInfo = result.customerInfoDo not rely on the anonymous id as a credential. It is a device scoped identifier and does not protect purchase history on shared devices.
Even with Trusted Entitlements (INFORMATIONAL) on the client, every server endpoint that serves paid content checks entitlement server side:
def get_premium_content(user_id):
body = revenuecat_get(f"/v1/subscribers/{user_id}") # secret key, no X-Platform
ent = body["subscriber"]["entitlements"].get("pro")
exp = ent and ent["expires_date"]
if ent is None or (exp is not None and parse(exp) <= parse(body["request_date"])):
raise Forbidden()
return contentOr read the entitlements your webhook handler stores (see rc-webhooks) and check their expiry per request, re-reading the customer before you deny an expired looking one (at most once every few minutes per user).
EntitlementVerificationMode is not explicitly DISABLED, and VerificationResult.FAILED is acted on.Purchases.logIn. Anonymous ids are only used for pre login flows.| Mistake | Why it hurts | Fix |
|---|---|---|
| Shipping the secret key in the app | An attacker who decompiles the APK can call admin REST endpoints | Public key in app, secret key only on server |
Leaving mode at DISABLED in production | A man in the middle can forge CustomerInfo responses | Set INFORMATIONAL (the default) and act on VerificationResult.FAILED |
| Treating the anonymous id as a credential | It is not secret and is shared across users of the same device | Call logIn with your authenticated user id |
Trusting customerInfo from the client on the server | A tampered client can claim any entitlement | Verify on the server via REST API or webhook driven DB |
RevenueCat/ai-toolkit
2aeae8c
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.