Backend Interview: How Would You Securely Govern W3C Baggage Propagation?

Question and scenario

Several microservices use the W3C baggage header for tenant, experiment, and request-source context. Some services cross company or data-domain boundaries, so OpenTelemetry correlation must remain while personal data and internal identifiers stay out of untrusted downstream systems.

What the interviewer is testing

• Separating Baggage from Trace Context and recognizing arbitrary key-value propagation.
• Applying trust-boundary allowlists, size limits, redaction, and deletion instead of blind forwarding.
• Balancing observability, compatibility, graceful degradation, and audit evidence.

Clarifying questions before answering

Clarify which services share a trust domain, the allowed-field catalog, maximum header size, browser or queue entry points, telemetry retention, and whether downstream systems persist Baggage. Clarify whether the goal is to block sensitive keys, restrict cross-domain propagation, or migrate custom headers.

30-second answer framework

I would treat Baggage as untrusted input. Parse and normalize it at ingress, then retain, rename, hash, or delete fields based on source, destination trust domain, and policy. The gateway limits key/value and total size, never copies raw values into logs or user responses, and uses an allowlist plus policy version at cross-domain egress. Traceparent is handled independently. If filtering fails, drop optional fields, continue the core request, and record an auditable policy action.

Step-by-step deep answer

1. Maintain a versioned field catalog: purpose, data class, allowed source and destination domains, maximum length, and logging permission.
2. Parse the standard format at ingress and reject invalid keys, control characters, oversized values, and duplicate conflicts. Keep a request digest, not the sensitive header.
3. Propagate an allowlist inside one trust domain. Across domains, send only minimized public keys, or an irreversible tenant alias or short-lived signed reference.
4. Add explicit filtering at OpenTelemetry injection points so automatic instrumentation cannot copy every Baggage item into spans, logs, or metric attributes.
5. Cap total bytes, item count, and hop count. On overflow, remove low-priority fields and emit an internal policy event without echoing sensitive data.
6. Re-evaluate policy at each egress; reuse the catalog for queues and asynchronous jobs. Never use Baggage as an authorization credential.
7. Audit field name, policy version, action, and destination, not the original value. Test synthetic leakage, size attacks, and multi-hop accumulation.

incoming baggage: tenant=acme,experiment=A,pii_email=alice@example.org
same-trust output: tenant=acme,experiment=A
cross-trust output: tenant_ref=hash:v3:...,experiment=A

High-quality sample answer

I would state first that Baggage is not an authentication or authorization carrier; every value is untrusted. A versioned field catalog drives parsing and limits at ingress, and allowlists govern same-domain propagation. Across trust domains, send only a minimized alias or short-lived reference. Handle OpenTelemetry trace context separately, filter automatic injection, and never log raw values. On overflow or unknown policy, drop optional fields, continue the core request, and record field name, action, and policy version. Multi-hop synthetic tests, queue-boundary tests, and audit queries verify that privacy risk is reduced without hiding it behind a healthy trace.

Common errors

• Treating Baggage as trusted identity, authorization, or tenant isolation.
• Allowing arbitrary keys across trust boundaries or relying only on a string blacklist.
• Writing the complete header into logs, traces, or error responses.
• Governing HTTP but forgetting queues, retries, and asynchronous jobs.
• Returning a 4xx for optional overflow, or silently dropping data without an audit event.

Follow-up questions and responses

What is the difference between Baggage and Trace Context?

Trace Context carries standard metadata needed for distributed tracing. Baggage is an application-defined key-value set that can work independently, so its semantics and privacy risks belong to the application.

Why prefer an allowlist over a blacklist?

Baggage keys have no fixed business semantics and new fields appear over time. An allowlist rejects unknown data by default, preventing a new service or vendor from spreading a sensitive value accidentally.

Should a filtering failure block the request?

If the field is only observational, drop it and continue. If a business flow requires it, return a recognizable policy error without echoing the value. The catalog should mark which fields are critical.

How do you prove raw values do not enter telemetry?

Run redaction tests at both the Collector and SDK, scan logs, span attributes, and metric labels, record names and policy versions rather than values, and alert on synthetic canaries.