Security

Security you can read, not just trust

How AppVero protects your data and your users’ — where it lives, how it’s encrypted, who can reach it, and how to report a problem. Documented in plain language so your team can assess it directly.

Report a vulnerabilityPrivacy policy

Security controls

  • Where data lives

    • AppVero runs on AWS.
    • Each workspace’s data — events, clicks, installs, configuration — is stored in a single AWS region.
    • Data only leaves that region through the exports, webhooks and postbacks you configure.
    • Raw-data exports are written straight from the database to the storage you choose.

  • Encryption

    • TLS for every connection: dashboard, APIs, SDK traffic and link domains.
    • Custom link domains get certificates automatically once their CNAME verifies.
    • Stored credentials — SDK and webhook secrets, export keys, Meta decryption keys and Play licence keys — are encrypted at rest.
    • Secrets are shown once when created; write-only credentials are never returned by the API.

  • Access control

    • API keys with least-privilege scopes: admin, read (GET only) and s2s (S2S events only).
    • Keys and SDK secrets are shown once, can be rotated, and can be revoked.
    • Dashboard sessions use HttpOnly, SameSite cookies; state-changing requests require a custom header.

  • Signed traffic

    • Every mobile SDK request is signed with HMAC-SHA256 and a versioned SDK secret.
    • Tagged mode records a signature status on every row; enforced mode rejects bad requests.
    • Webhooks carry an HMAC-SHA256 signature with a timestamp.

  • Safe outbound requests

    • Postbacks, webhooks, email-proxy and export requests refuse private, loopback and link-local addresses after DNS resolution.
    • Postbacks don’t follow redirects; query values are redacted in delivery logs.
    • Exports without your own credentials can only write to an AppVero-hosted bucket under your app’s prefix.

  • Data minimisation

    • SDKs send nothing before start(); opt-out wipes the queue.
    • The iOS SDK reads the IDFA only with ATT consent and never shows the prompt itself.
    • Paid-media iOS installs without consent are measured in aggregate, not fingerprinted.
SDK signing

Spoofed SDK traffic is visible — or rejected

Each app has versioned SDK secrets. The server accepts timestamps within ±600 seconds, records the signature status on every row in tagged mode, and returns 401 with a reason code in enforced mode.

Signature (protocol v1)Text
string_to_sign = "v1" + "\n" +
                 HTTP_METHOD (uppercase) + "\n" +
                 PATH (no query string, e.g. /v1/sdk/install) + "\n" +
                 X-AV-Timestamp + "\n" +
                 lowercase_hex(SHA-256(uncompressed body bytes))
signature      = base64url_no_padding(HMAC-SHA256(key = SDK secret, string_to_sign))
header         X-AV-Signature: v1:<sdk secret id>:<signature>
Fraud reason codes

Every decision, explained

The public, stable taxonomy behind every rejected install, flagged install and excluded click.

Public fraud reason codes, taxonomy v1
CodeApplies toOutcome
sig_missingSDK requestFlagged (tagged mode) / rejected 401 (enforced)
sig_invalidSDK requestFlagged / rejected
sig_stale_tsSDK requestFlagged / rejected
id_malformedInstallFlagged
id_zeroInstallFlagged
ip_anonymousInstall, clickRejected (install) / click excluded from matching
click_injectionInstallRejected
ctit_too_shortInstallFlagged
bot_uaClickClick excluded from matching
click_expiredInstallNot credited (falls through to next candidate)
click_app_mismatchInstallNot credited
receipt_invalidPurchase eventRevenue excluded from validated revenue
receipt_duplicatePurchase eventRevenue excluded
install_replayInstallRejected
Full rules for each code
Compliance

Where we are today

AppVero does not hold SOC 2 or ISO 27001 certification today. An independent SOC 2 audit is on our roadmap; until then, this page describes our controls so your security team can assess them directly — and we’re happy to answer questionnaires.

Our privacy policy explains how we handle personal data under the GDPR and other applicable data-protection laws. Customers remain responsible for notices and consent in their own apps and websites.

Responsible disclosure

Found a vulnerability? Tell us.

Email [email protected]. We welcome reports from security researchers and will work with you to understand and fix the issue.

[email protected]

Please include

  • The affected host, endpoint or SDK and version
  • Steps to reproduce, and the impact you observed
  • How we can reach you for follow-up questions

Please don’t

  • Access, change or delete data that isn’t yours
  • Degrade the service (no denial-of-service or load testing)
  • Disclose the issue publicly before we’ve had a reasonable chance to fix it

Our commitment

  • We’ll acknowledge your report and keep you updated
  • We won’t pursue good-faith research that follows these guidelines
  • We’ll credit you, if you’d like, once the issue is fixed

Machine-readable contact: /.well-known/security.txt