Problem statement
TransportDescriptor.config uses google.protobuf.Struct which allows arbitrary JSON-like data to be passed through the transport layer to connectors. Since connectors interpret this as configuration, a malicious or buggy upstream step could inject configuration directives (e.g., redirect endpoints, disable TLS, change credentials).
message TransportDescriptor {
string name = 1;
string kind = 2;
string mode = 3;
google.protobuf.Struct config = 4; // Arbitrary, unvalidated
}
This appears in every packet via the transports repeated field in DataRequest, PublishRequest, and HubPushRequest.
Proposed change
Option A — Replace with strongly-typed config (preferred if transport types are known):
message TransportConfig {
oneof config {
GrpcTransportConfig grpc = 1;
// future transports
}
}
message TransportDescriptor {
string name = 1;
string kind = 2;
string mode = 3;
TransportConfig config = 4;
}
Option B — Keep Struct but document validation requirements:
// config carries transport-specific settings. Implementations MUST validate
// and sanitize config values against an allowlist of expected keys before
// applying them. Do not pass config values directly to connection or TLS
// setup without validation.
google.protobuf.Struct config = 4;
Option C — Hybrid: keep Struct for extensibility but add buf.validate constraints on struct depth/size.
Affected area
Compatibility / migration
Option A is a breaking change — requires downstream migration in all consumers.
Option B is comment-only — no wire impact.
Option C is additive — validation constraints don't break existing valid payloads.
Additional context
Identified during security review. Attack scenario: malicious workflow step crafts TransportDescriptor.config containing {"redirect_endpoint": "http://attacker.com", "disable_tls": true}, and a naive connector implementation applies it.
Problem statement
TransportDescriptor.configusesgoogle.protobuf.Structwhich allows arbitrary JSON-like data to be passed through the transport layer to connectors. Since connectors interpret this as configuration, a malicious or buggy upstream step could inject configuration directives (e.g., redirect endpoints, disable TLS, change credentials).This appears in every packet via the
transportsrepeated field inDataRequest,PublishRequest, andHubPushRequest.Proposed change
Option A — Replace with strongly-typed config (preferred if transport types are known):
Option B — Keep
Structbut document validation requirements:Option C — Hybrid: keep
Structfor extensibility but addbuf.validateconstraints on struct depth/size.Affected area
Compatibility / migration
Option A is a breaking change — requires downstream migration in all consumers.
Option B is comment-only — no wire impact.
Option C is additive — validation constraints don't break existing valid payloads.
Additional context
Identified during security review. Attack scenario: malicious workflow step crafts
TransportDescriptor.configcontaining{"redirect_endpoint": "http://attacker.com", "disable_tls": true}, and a naive connector implementation applies it.