Last updated 2026-04-12
Security
Security is not an afterthought at stubkit. Every design choice — from how we store your provider credentials to how we verify inbound webhooks — is made with the assumption that any single layer can be compromised, and the others must still hold.
Provider credential storage
Apple private keys, Google service account JSON files, and Stripe webhook signing secrets are encrypted at rest using authenticated symmetric encryption with a master key held exclusively in our secure key vault. The master key is never written to our application databases and never transmitted over the network. Even a full database compromise would not expose your credentials.
API key storage
API keys issued to customers are hashed with a keyed cryptographic hash function using a server-side secret before being persisted. The raw key is displayed to the administrator exactly once at creation; afterwards only the first twelve characters (a prefix) are visible in the dashboard. Revoked keys are tombstoned and rejected on every request.
Webhook signature verification
Every inbound webhook is cryptographically verified before any persistence:
- Apple App Store Server Notifications v2 are verified against the signed JWS payload and the Apple certificate authority chain
- Google Play Real-Time Developer Notifications are authenticated via the OpenID Connect push token signed by Google
- Stripe webhooks are verified by HMAC-SHA256 signature with a five-minute replay tolerance
Unverified payloads are rejected and never reach the database.
Idempotency
Every mutating event carries a stable idempotency key derived from the provider's own unique identifiers. Our storage layer enforces uniqueness on that key so retried webhook deliveries — which are normal for Apple, Google, and Stripe — cannot create duplicate state or double-charge an entitlement.
Per-user state isolation
Each end user's subscription state is handled by an isolated, serialized execution context. Concurrent webhook deliveries for the same user are processed one at a time, ruling out race conditions without distributed locking or optimistic retry loops.
Access control
The stubkit dashboard is protected by single sign-on with an email allowlist enforced at the edge, before any request reaches our application. Administrative API calls additionally require a scoped API key with explicit grants — read-only, grant management, analytics, and others — so a compromised credential can only do what it was explicitly authorized to do.
Audit trail
Every administrative action, state transition, and webhook event is recorded with a timestamp and actor identity in an append-only audit log. Immutable copies of every raw webhook payload are retained for two years to enable full replay and forensic review.
Transport security
TLS 1.2 or higher is enforced on every public endpoint with modern cipher suites. HSTS is set on all subdomains. All internal service calls are encrypted in transit.
Responsible disclosure
We welcome good-faith security research. Please report vulnerabilities to security@stubkit.com. We acknowledge reports within one business day, commit to a coordinated disclosure timeline, and credit researchers who follow responsible-disclosure practices.