← Back to home

Security

Encore stores third-party platform credentials so we can keep publisher integrations self-serve and our subscription analytics accurate. This page is the public record of what we hold, what we do not hold, and how we protect it.

What we hold (and what we don’t)

Both store credentials are continuously custodied, encrypted at rest with domain-separated keys, and decrypted only through a single chokepoint module that audits each access.

Google Play service account JSON

Continuous

Custody: Stored, encrypted at rest

Why this model: Real-time Developer Notifications (RTDN) deliver only a pointer to a transaction. Resolving that pointer to a canonical purchase state requires a signed call to the Google Play Developer API, so the service account must be available continuously.

Scope we ask for: Lowest-privilege role the feature requires — read-only "View app information" for analytics-only setups; an additional financial-data or store-presence scope is only requested when the publisher opts into in-portal subscription writers.

Apple App Store Connect .p8 API key

Continuous

Custody: Stored, encrypted at rest

Why this model: Drives opportunistic inventory refreshes and publisher-initiated subscription writes from the portal without re-prompting on every action. Decryption is gated through a single chokepoint module and audited per access.

Scope we ask for: App Manager scoped to a single app. Write scope is only required when the publisher opts into the in-portal subscription-product writers.

Controls in place

Every control below is enforced by code or infrastructure — not policy alone. Each one has a corresponding internal acceptance criterion that must be met before any code accepting credentials is deployed.

Domain-separated encryption keys

Stored credentials are encrypted with AES-256-GCM. The data-encryption key for store credentials is distinct from the key used for subscription signing material, so a leak of one does not compromise the other.

Single-purpose access path

Credential decryption goes through a single chokepoint module (CredentialAccessor). A CI-enforced ESLint rule prevents direct access to the encryption key from anywhere else in the codebase.

Audit log on every access

Every credential decryption, sync, upload, or revocation is recorded with structured event metadata. Audit records contain no credential material and are routed to a dedicated, immutable log sink.

Network egress allow-list

Backend pods that handle credentials may only reach an explicit list of upstream endpoints (Apple, Google, our own internal services). Any outbound connection to a non-allowlisted domain triggers an alert.

Anomaly detection

Decrypt-rate spikes, failed decrypts, off-hours access patterns, and direct (non-application) reads of the encrypted secret all generate alerts to the on-call rotation.

Self-service revocation

Publishers can revoke or re-sync inventory at any time from the publisher portal. Removal is immediate and clears the stored snapshot.

Questions publishers ask

What if a credential is leaked from your side?

Our incident-response runbook covers single-credential and master-key compromise scenarios end-to-end. We notify affected publishers within the timeline required by the relevant data-protection regime (e.g. GDPR Article 33: 72 hours). Forensic detail comes from the credential audit log.

Can I see what you currently hold for my app?

Yes — the publisher portal surfaces the credentials currently in custody for each app, the last-synced timestamp for inventory snapshots, and a one-click revocation control. There is no version of your stored data that is invisible to you.

Do you encrypt backups?

Database backups are encrypted at rest with a separate key from application data, on a different rotation cycle. Backup restoration paths are part of the quarterly disaster-recovery drill.

How do I report a vulnerability?

Email support@encorekit.com with as much detail as you can share. We acknowledge within one business day and target a fix or mitigation within 30 days for the disclosure to remain coordinated. We do not currently run a paid bounty program.

Reporting a vulnerability

If you believe you’ve found a security issue, email us. Please include enough detail to reproduce the issue. We acknowledge within one business day and aim to keep you informed through resolution.

support@encorekit.com

Related pages: