Security

Yavio is designed with a security-first approach. This page covers how the platform protects sensitive data and prevents abuse.

PII Stripping

The PII stripping engine runs on every event before it reaches ClickHouse. It is ON by default and cannot be disabled in Community or Cloud Free tiers.

Defense in Depth

PII stripping uses a two-layer strategy:

1. SDK layer — a lightweight, non-configurable best-effort pass strips common PII patterns before events leave the developer's process
2. Ingestion API layer — a full configurable scrub runs as the authoritative safety net before writing to ClickHouse

This ensures PII is caught regardless of SDK version and provides redundancy if either layer has a bug.

What Gets Redacted

Both layers scan all string fields in the event, including nested JSON in metadata. They target identity data — business values like prices, cities, dates, and quantities are preserved.

API Key Authentication

Server-side SDKs authenticate with a project API key (yav_... prefix). Each project gets a unique key, managed from the dashboard.

• API keys are sent as Authorization: Bearer <key> headers
• The ingestion API validates keys against PostgreSQL with an in-memory LRU cache (60s TTL, 10,000 entries)
• Revoked keys are rejected within 60 seconds of revocation

Key Scoping

Each API key is scoped to a single project within a workspace. A key can only write events to its own project — it cannot read data, access other projects, or perform administrative actions.

Widget JWT Authentication

Widgets never receive the project API key. Instead, the server-side proxy mints a short-lived JWT for each widget interaction:

JWT Claims

Even if a widget JWT is extracted from the browser iframe, it is useless after 15 minutes and cannot be used to send events for other traces.

Trace Validation

Every event in a widget JWT batch must have a traceId matching the JWT's tid claim. The ingestion API rejects the entire batch if any event has a mismatched trace ID.

Rate Limiting

Rate limit state is stored in memory. Exceeded limits return 429 Too Many Requests with a Retry-After header.

Reverse Proxy Requirement

IP-based rate limiting relies on the X-Forwarded-For header to identify clients, since the application sits behind a reverse proxy and cannot see the original socket address directly.

Your reverse proxy must overwrite (not append to) the X-Forwarded-For header with the client's real IP. If the proxy merely appends, a client can send a forged header value to get a fresh rate-limit bucket on every request.

Example Nginx configuration:

proxy_set_header X-Forwarded-For $remote_addr;

Example Caddy configuration:

header_up X-Forwarded-For {remote_host}

Without this, IP-based rate limits can be bypassed trivially.

Event Field Size Limits

Individual event fields are validated against maximum size limits to prevent storage exhaustion:

Truncation is preferred over rejection for non-critical fields to avoid data loss.

Pipeline Guarantees