How Kopra Secures Your Customer Data

When you embed Kopra into your product, your customers' data flows through our infrastructure. That means security is not a feature we bolt on later. It is built into every layer: data access, authentication, token generation, API endpoints, webhook delivery, and hosting.

This post walks through each security layer, so you can evaluate whether Kopra meets your production requirements.

1. Multi-Tenant Data Isolation

Every row in Kopra's database is scoped to your account and, where applicable, to your customer's tenant. These identifiers are not optional filters. They are mandatory parameters enforced at the data access layer on every query.

There is no code path that retrieves data without account and tenant scoping. Even if a bug exists in one query, cross-tenant data leakage requires bypassing both the authentication middleware (which sets the account scope from a verified credential) and the data access layer (which requires it on every call).

Deleted records are excluded from all query results. This prevents accidentally exposing data that a customer has removed.

2. Three Authentication Methods

Kopra uses three distinct authentication mechanisms, each designed for a specific integration pattern.

Session Authentication (Dashboard)

Logged-in users interact with Kopra's management dashboard through session-based auth with HTTP-only cookies and standard CSRF protections. This is the only method that provides access to account management, billing, and field group configuration.

JWT Tokens (Embeds)

When you embed Kopra's field editor into your product via an iframe, authentication happens through short-lived JWT tokens. Your backend requests a token from Kopra's API, scoped to a specific account and tenant. The token is then passed to the iframe, which uses it for all subsequent requests.

Tokens contain only the minimal claims needed for data scoping. No personally identifiable information, no permissions beyond tenant scope. Tokens are cryptographically signed and verified on every request.

API Keys (Server-to-Server)

For REST API integrations, Kopra uses API keys passed via the X-API-Key header. Keys are generated with cryptographic randomness. Only a one-way hash is stored in the database. The raw key is shown once at creation and never stored or logged. This means that even a full database breach does not expose usable API keys.

3. Token Security

Embed tokens have several safeguards beyond basic JWT signing:

• Short-lived by default with a configurable expiry and a hard maximum cap. Use the minimum duration your UX requires.
• Rate-limited token generation to prevent brute-force attempts and limit the blast radius of a compromised API key.
• Minimal claims: tokens contain only the identifiers needed for data scoping.
• Algorithm restriction: token verification explicitly requires a single signing algorithm, preventing algorithm confusion attacks.

4. API Security

All API routes pass through layered middleware before reaching any business logic.

Rate limiting is applied at multiple levels. Authentication-related endpoints have stricter limits than general API calls. Rate limit headers follow the standard RateLimit-* format so clients can implement backoff.

Input validation uses schema-based validation for all request bodies. Field definitions, field values, and configuration payloads are parsed and validated before they reach the database layer. Invalid input returns structured error responses with specific field-level messages.

Error handling follows HTTP semantics consistently: 400 for validation errors, 401 for missing or invalid credentials, 403 for insufficient permissions, 404 for missing resources (with tenant scoping, so you cannot probe for resources in other tenants), and 429 for rate limit violations.

Request logging records the method, path, status code, and response time for every API call, enabling anomaly detection and incident investigation.

5. Webhook Security

When Kopra dispatches webhook events (on field group, field, or field value changes), each delivery is cryptographically signed using a per-endpoint secret. The signature is sent in the X-Kopra-Signature header.

Your webhook handler should verify the signature using constant-time comparison before processing the payload. See the webhooks guide for implementation examples.

Each webhook endpoint has its own secret, generated at creation. If one endpoint's secret is compromised, other endpoints remain secure. Failed deliveries retry with exponential backoff up to a maximum number of attempts before being marked as permanently failed.

6. Infrastructure

Kopra is hosted in Europe, with all data stored in European data centers.

• TLS encryption for all traffic with automatic certificate management
• Container isolation with separate containers for the web server, database, and background job runner
• Parameterized queries for all database access, preventing SQL injection
• Reverse proxy providing automatic HTTPS, HTTP/2, and request routing

7. What Kopra Does Not Yet Have

Transparency matters. Here is what is not yet in place:

• SOC 2 certification: Kopra has not undergone a SOC 2 audit. If your compliance team requires this, we are not there yet.
• GDPR Data Processing Agreement (DPA): A formal DPA is not currently available. Kopra stores data in Europe and does not transfer it outside the EU, but we do not yet offer a signed DPA.
• Single-tenant deployment: All customers share the same infrastructure. Dedicated instances are not available today.
• Application-level encryption at rest: Data is stored on encrypted volumes at the infrastructure level, but Kopra does not implement additional application-level encryption for field values.
• Audit log export: Audit logs are stored internally and visible in the dashboard, but there is no API endpoint for exporting them to your SIEM.

These are on the roadmap. If any of them are blockers for your use case, reach out and we can discuss timelines.

Security Checklist for Production

Before going live with Kopra in your production environment, verify each of these:

• Use a strong signing secret and store it in environment variables, not in code
• Keep API keys server-side only. Never expose them in client-side JavaScript, mobile apps, or public repositories
• Set short token expiry times. Use the minimum duration your UX requires.
• Verify webhook signatures in your handler using constant-time comparison. Do not skip this step even in development.
• Rotate API keys periodically. Kopra supports multiple active keys, so you can create a new key before deactivating the old one.
• Configure CORS origins in production. Do not leave the default wildcard.
• Monitor rate limit headers in your API client. Implement exponential backoff when you receive 429 responses.
• Review the audit log in the Kopra dashboard regularly for unexpected actions or access patterns.
• Use HTTPS for webhook endpoints. Kopra will deliver to HTTP URLs, but the payload travels in plaintext without TLS.
• Test token expiry handling in your embed integration. When a token expires mid-session, your app should request a new one gracefully.

If you have questions about any of these security layers or need details for a vendor security questionnaire, contact us at support@kopra.dev.