Surfaced by the security re-review of #1983 (review 5289004003), re-verified at 85e5de84. Two related observations about the same leg.
1. The payload goes to the broker verbatim
EventService.php (~:1804):
$messageData = $message->getObject();
$cloudEvent = ($messageData['payload'] ?? []);
...
$result = $transport->publish(
publication: $this->brokerPublication(cloudEvent: $cloudEvent, ...),
configuration: $this->brokerSettings(subscriptionData: $subscriptionData)
);No bound, no redaction, no declared shape. For a Dutch government product a CloudEvent data block can carry a BSN.
To be fair to the design: delivering the payload is the point of a broker, so redacting the delivered body would break the feature. This is a data-minimisation and documentation gap, not a leak — but it is one that should be answered deliberately rather than by default. Either:
2. The broker leg writes no trace at all
Checked while verifying the above: the only addStep in EventService is at :629, on the webhook/call leg, and that one already redacts both input and output through SensitiveFieldRegistry (:615, :622).
The broker leg records none. It calls recordConfigurationError() and logs on throw, but a successful broker dispatch leaves no trace step.
So the asymmetry is not "webhook redacts, broker leaks" — it is "webhook is auditable, broker is not". For a government product that is its own problem: a dispatch that delivered personal data to an external system with no trace entry cannot be answered for afterwards.
Surfaced by the security re-review of #1983 (review 5289004003), re-verified at
85e5de84. Two related observations about the same leg.1. The payload goes to the broker verbatim
EventService.php(~:1804):No bound, no redaction, no declared shape. For a Dutch government product a CloudEvent
datablock can carry a BSN.To be fair to the design: delivering the payload is the point of a broker, so redacting the delivered body would break the feature. This is a data-minimisation and documentation gap, not a leak — but it is one that should be answered deliberately rather than by default. Either:
datafor broker-dispatched subscriptions, or2. The broker leg writes no trace at all
Checked while verifying the above: the only
addStepinEventServiceis at:629, on the webhook/call leg, and that one already redacts both input and output throughSensitiveFieldRegistry(:615,:622).The broker leg records none. It calls
recordConfigurationError()and logs on throw, but a successful broker dispatch leaves no trace step.So the asymmetry is not "webhook redacts, broker leaks" — it is "webhook is auditable, broker is not". For a government product that is its own problem: a dispatch that delivered personal data to an external system with no trace entry cannot be answered for afterwards.