SDP-2095 fix: prevent cross-tenant access via tenant-unscoped API-key validation cache

[hypekostas]

What

In the API-key authentication middleware, the in-memory validation cache now namespaces every entry by the request tenant: the lookup key is now the composite tenant.ID + ":" + rawKey.

When the tenant can't be resolved from context, the cache is bypassed entirely and validation goes straight to the schema-scoped DB lookup, so no unscoped entry is ever stored. A cross-tenant request therefore misses the cache and falls through to the tenant-routed DB lookup, which rejects it, restoring the tenant boundary the cache was circumventing.

Why

Previously, the API-key auth middleware cached key-validation results in a process-wide in-memory cache keyed only on the raw key string, with no tenant component. On a cache hit it returned the cached *data.APIKey after an expiry check only, skipping the schema-scoped DB lookup that is the sole mechanism binding a key to its tenant.

Because the request tenant came from the attacker controlled SDP-Tenant-Name header, a key valid for tenant A could, once its validation was cached by a normal request, be replayed with tenant B's name and operate against tenant B's schema.

Known limitations

This fix does not implement the bug reporter's defense in depth suggestion of "store and verify a tenant binding on the API key itself", for the following reasons:

• Embedding the tenant in the key string or its hash verification: The composite key fix already closes this for every key, existing and future, without requiring users to manually rotate API keys to benefit from the added protection.

• A tenant_id column on api_keys table: in a schema-per-tenant model this column carries no information the schema doesn't already encode: every row in sdp_<X>.api_keys necessarily has tenant_id = X, and a row can only be read through a schema-scoped lookup. The column therefore can't reject anything schema isolation didn't already reject. Mechanically it would just reproduce the composite-key check anyway (compare the cached key's tenant_id to the request tenant, no extra read), since re-reading the row from the DB on every request would defeat the cache.

Testing

Two new tests in internal/serve/middleware/api_keys_middleware_test.go:

• Test_APIKeyOrJWTAuthenticate_CrossTenantIsolation: An end-to-end HTTP test through real middleware. Ristretto writes to the cache asynchronously and the HTTP layer can't force a flush, so the cross-tenant replay always hits a cold cache and returns 401, necessitating the second test:
• Test_apiKeyAuthenticator_validate_CrossTenantIsolation: calls cache.Wait() to make the entry genuinely warm, so it exercises the actual tenant-scoped cache lookup.

Checklist

• Title follows SDP-1234: Add new feature or Chore: Refactor package xyz format. The Jira ticket code was included if available.
• PR has a focused scope and doesn't mix features with refactoring
• Tests are included (if applicable)
• CHANGELOG.md is updated (if applicable)
• If contracts changed, run the Contract WASM Artifacts workflow and open a PR to update the WASMs on dev
• CONFIG/SECRETS changes are updated in helmcharts and deployments (if applicable)
• Preview deployment works as expected
• Ready for production

[Copilot]

Pull request overview

Fixes a multi-tenant security gap in the API-key authentication middleware where ristretto cache entries were previously keyed only by the raw API key, allowing cached validation results to be replayed across tenant schemas.

Changes:

• Namespace API-key validation cache entries by tenant (tenant.ID + ":" + rawKey) and bypass caching entirely when tenant cannot be resolved.
• Add integration-style and white-box tests to verify cross-tenant replay fails on both cold-cache and warm-cache paths.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
internal/serve/middleware/api_keys_middleware.go	Tenant-scopes the in-memory API-key validation cache to prevent cross-tenant cache hits.
internal/serve/middleware/api_keys_middleware_test.go	Adds regression tests covering cold-cache and warm-cache cross-tenant isolation.