Strip sensitive inbound headers before forwarding to interceptor URLs

[vdemeester]

Summary

When the EventListener processes a webhook, it clones all inbound HTTP headers and includes them in the InterceptorRequest sent to interceptors (pkg/sink/sink.go:468):

request := triggersv1.InterceptorRequest{
    Body:   string(event),
    Header: in.Header.Clone(),   // all inbound headers forwarded verbatim
    ...
}

This means headers like Authorization, X-Hub-Signature-256, X-Gitlab-Token, and other webhook credentials are forwarded to every interceptor in the chain. For built-in interceptors using clientConfig.service, this is expected — they need these headers for signature validation. However, for interceptors using clientConfig.url, this creates a credential exfiltration risk if the URL points to an attacker-controlled or compromised endpoint.

Proposed Fix

Evaluate the following options:

1. Strip sensitive headers for url-based interceptors only — remove Authorization, X-Hub-Signature-*, X-Gitlab-Token, X-Bitbucket-* headers when the interceptor uses clientConfig.url rather than clientConfig.service. Service-based interceptors would continue to receive all headers.

2. Allowlist approach — only forward headers that the interceptor explicitly declares it needs via a new field in the ClusterInterceptor spec.

3. Document the risk — if the header forwarding is considered by-design for flexibility, document that url-based interceptors receive all inbound headers including credentials.

Considerations

• The built-in interceptors (github, gitlab, bitbucket, slack) rely on receiving signature/token headers for validation — any change must not break them
• Custom interceptors may also legitimately need access to inbound headers
• Option 1 is the least disruptive since built-in interceptors all use clientConfig.service