Validate synthetic ID format on inbound header and cookie values

[prk-Jr]

Summary

• Inbound synthetic IDs from the x-synthetic-id header and synthetic_id cookie were accepted without validation, allowing injection of arbitrary strings into response headers, cookies, and third-party API calls
• Adds a private is_valid_synthetic_id() validator (64 lowercase hex + . + 6 alphanumeric) with an O(1) length check first to bound all downstream work; invalid values are silently discarded and a fresh ID is generated in their place
• Hardens logging by ensuring the raw ID value never appears in warn logs and demoting synthetic ID values from INFO to DEBUG to avoid recording pseudonymous identifiers in production log pipelines

Changes

File	Change
crates/common/src/synthetic.rs	Add is_valid_synthetic_id() production validator; validate in get_synthetic_id(); add debug_assert! in generator; demote ID values to debug!; new rejection + fallthrough tests
crates/common/src/test_support.rs	Add shared VALID_SYNTHETIC_ID constant
crates/common/src/proxy.rs	Update test fixture to use VALID_SYNTHETIC_ID
crates/common/src/integrations/registry.rs	Update test fixture to use valid-format cookie value
docs/guide/synthetic-ids.md	Document inbound validation behaviour and clarify HMAC determinism
CHANGELOG.md	Add ### Security entry under [Unreleased]

Closes

Closes #412

Test plan

• cargo test --workspace
• cargo clippy --all-targets --all-features -- -D warnings
• cargo fmt --all -- --check
• JS format: cd crates/js/lib && npm run format
• Docs format: cd docs && npm run format

Checklist

• Changes follow CLAUDE.md conventions
• No unwrap() in production code — use expect("should ...")
• Uses tracing macros (not println!)
• New code has tests
• No secrets or credentials committed

[ChristianPavilonis]

see below

Re-posting as inline comments

[ChristianPavilonis]

Clean, well-executed security hardening. Validation logic is correct and thoroughly tested. Approving with one suggestion inline.

Strengths:

• O(1) length check gates all downstream work — good defense against oversized input on an edge server
• Lowercase hex enforcement prevents intermediary case-normalization from creating fake-valid IDs
• debug_assert! in the generator ensures validator and generator never drift apart
• Logging hygiene — invalid values logged with len={} only, never the raw attacker-controlled string
• Excellent test coverage with 8+ new/updated test cases
• Shared VALID_SYNTHETIC_ID constant eliminates test fragility across 3 modules
• CHANGELOG and docs properly updated

Note: The lol_html bump (e295f3a) in Cargo.toml/Cargo.lock appears to be a merge artifact from main — unrelated to the synthetic ID validation. Not a problem, just flagging it.

[aram356]

Summary

Well-executed security hardening PR that validates synthetic ID format on inbound header and cookie values. The validation logic is correct and test coverage is thorough. One gap in the revocation path needs attention.

Blocking

🔧 wrench

• Revocation path bypasses validation: existing_ssc_cookie in publisher.rs:379-387 is read from the raw cookie jar before get_or_generate_synthetic_id runs validation. This raw, unvalidated value is then: (1) logged at log::info! level (line 381) — potentially logging attacker-controlled content, and (2) passed to delete_consent_from_kv as a KV store key (line 387) — allowing a crafted cookie value to target arbitrary KV keys for deletion. This is the same class of injection this PR aims to fix. Suggested fix: make is_valid_synthetic_id pub(crate) and validate existing_ssc_cookie before use, or restructure so the already-validated synthetic ID is reused for revocation. At minimum, track as a follow-up issue.

Non-blocking

🏕 camp site

• Clarify old vs new validation layers (cookies.rs:38): The old synthetic_id_has_only_allowed_chars (permits [a-zA-Z0-9._-]) remains for outbound cookie sanitization, while the new is_valid_synthetic_id in synthetic.rs is strictly tighter for inbound validation. A brief comment noting this layered relationship would help future readers.

⛏ nitpick

• PR body references stale crates/common/src/ paths: actual paths are crates/trusted-server-core/src/...
• PR checklist says "tracing macros": project uses log crate, not tracing

CI Status

• fmt: PASS
• clippy: PASS
• rust tests: PASS
• js tests: PASS