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.

[ChristianPavilonis]

suggestion (P2): Tests cover valid header, valid cookie, invalid header → cookie fallthrough, and more — but there's no test confirming that when both header and cookie contain valid-but-different IDs, the header wins. The behavior is implicitly correct from code structure, but an explicit test would document the priority semantics.

Suggested change

	}
	#[test]
	fn test_get_synthetic_id_header_takes_precedence_over_cookie() {
	let cookie_id = "b2a1c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0b1a2.Zx98y7";
	let req = create_test_request(vec![
	(HEADER_X_SYNTHETIC_ID, VALID_SYNTHETIC_ID),
	(
	header::COOKIE,
	&format!("{}={}", COOKIE_SYNTHETIC_ID, cookie_id),
	),
	]);
	let result = get_synthetic_id(&req).expect("should succeed");
	assert_eq!(
	result,
	Some(VALID_SYNTHETIC_ID.to_string()),
	"should prefer header over cookie"
	);
	}