A04: scrub streaming responses in the SanitizeInterceptor #21

New issue

Closed

opened 2026-08-13 09:35:05 +00:00 by nalum · 0 comments

nalum commented

2026-08-13 09:35:05 +00:00

Owner

WrapStreamingHandler returns next untouched (internal/services/svc/sanitize.go:88-90), so the structural scrub guarantee is unary-only. Currently benign: the only streams are Watch (entity-name strings) and Subscribe (Notification — no scrub-map fields). But a future streaming RPC that emits a User would leak password_hash/pin_hash with nothing failing.

Fix: scrub per-send in a wrapped conn, or add a test that pins "no streamed message type embeds a scrub-map type" so the gap cannot open silently.

Source: OWASP Top 10 (2025) audit of v1.1.0, 2026-08-13. File references point at the v1.1.0 tree.

`WrapStreamingHandler` returns `next` untouched (`internal/services/svc/sanitize.go:88-90`), so the structural scrub guarantee is unary-only. Currently benign: the only streams are `Watch` (entity-name strings) and `Subscribe` (`Notification` — no scrub-map fields). But a future streaming RPC that emits a `User` would leak `password_hash`/`pin_hash` with nothing failing. **Fix**: scrub per-send in a wrapped conn, or add a test that pins "no streamed message type embeds a scrub-map type" so the gap cannot open silently. --- Source: OWASP Top 10 (2025) audit of `v1.1.0`, 2026-08-13. File references point at the `v1.1.0` tree.

nalum added this to the v1.1.0 security audit milestone

2026-08-13 09:35:05 +00:00

nalum added the

security

severity/low

labels

2026-08-13 09:35:05 +00:00

nalum added reference refs/tags/v1.1.0

2026-08-13 09:37:48 +00:00

nalum referenced this issue from a commit

2026-08-13 10:07:35 +00:00

fix(svc): scrub streaming responses in the sanitize interceptor