Search before asking
Description
Two gaps in connector-http-base that affect every HTTP sub-connector authenticating with a header — Klaviyo, Jira, Notion, Zendesk, Shopify and the rest. Raised by @DanielLeens while reviewing #11028, where they are out of scope: they are not specific to that connector, and fixing them in one module would make it the exception rather than the fix.
1. No scheme validation before an auth header is attached.
HttpParameter.buildWithConfig accepts whatever url it is given and the sub-connectors add their credential header to it. Nothing checks that the URL is https, so a configuration pointing at http:// sends the token in clear text over the network, and nothing in the job says so.
2. The credential sits in a Lombok @Data object.
HttpParameter is annotated @Data and holds headers, which is where every sub-connector puts its token:
@Data
public class HttpParameter implements Serializable {
protected Map<String, String> headers;The generated toString() therefore includes the credential verbatim. Anything that logs the parameter object — a debug line, an exception message that interpolates it — writes the token to the log.
Suggested fixes
For 1, reject a non-https URL when a credential header is present, or warn loudly. Rejecting outright would be a behaviour change for anyone testing against a local mock over plain HTTP, so a warning with an opt-out may be the kinder path; the choice belongs to the maintainers.
For 2, exclude headers from the generated toString() — @ToString.Exclude on the field, or a hand-written toString that masks the values. Masking rather than omitting keeps the field useful for debugging.
Are you willing to submit a PR?
Happy to take either or both, once the maintainers say which direction they prefer for the first one.
Code of Conduct
Search before asking
Description
Two gaps in
connector-http-basethat affect every HTTP sub-connector authenticating with a header — Klaviyo, Jira, Notion, Zendesk, Shopify and the rest. Raised by @DanielLeens while reviewing #11028, where they are out of scope: they are not specific to that connector, and fixing them in one module would make it the exception rather than the fix.1. No scheme validation before an auth header is attached.
HttpParameter.buildWithConfigaccepts whateverurlit is given and the sub-connectors add their credential header to it. Nothing checks that the URL ishttps, so a configuration pointing athttp://sends the token in clear text over the network, and nothing in the job says so.2. The credential sits in a Lombok
@Dataobject.HttpParameteris annotated@Dataand holdsheaders, which is where every sub-connector puts its token:The generated
toString()therefore includes the credential verbatim. Anything that logs the parameter object — a debug line, an exception message that interpolates it — writes the token to the log.Suggested fixes
For 1, reject a non-
httpsURL when a credential header is present, or warn loudly. Rejecting outright would be a behaviour change for anyone testing against a local mock over plain HTTP, so a warning with an opt-out may be the kinder path; the choice belongs to the maintainers.For 2, exclude
headersfrom the generatedtoString()—@ToString.Excludeon the field, or a hand-writtentoStringthat masks the values. Masking rather than omitting keeps the field useful for debugging.Are you willing to submit a PR?
Happy to take either or both, once the maintainers say which direction they prefer for the first one.
Code of Conduct