Thanks for the feedback. Do you think it's feasible to think of a
change to Camel along these lines, at least for certain components /
protocols? Echoing headers for HTTP for example could allow a
malicious client to mess with how caches store responses.
Colm.
On Mon, Feb 7, 2022 at 10:53 AM Zoran Regvart <zo...@regvart.com> wrote:
>
> Yeah,
> this is problematic, but it is endemic to the way Camel is
> architected. In Syndesis we opted for an allow-list approach, i.e. a
> header will be echoed back only if explicitly configured to do so.
>
> zoran
>
> On Fri, Feb 4, 2022 at 1:03 PM Colm O hEigeartaigh <cohei...@apache.org>
> wrote:
> >
> > Hi,
> >
> > It seems Camel has a default behaviour of echoing client headers, at
> > least for the CXF component that I tested with, e.g.:
> >
> > from("cxf://http://localhost:8000/service.endpoint?dataFormat=POJO&serviceClass="beans.CXFdemobean";)
> > .log("message");
> >
> > Calling it with: curl -H "xyz: whatever"
> > http://localhost:8000/service.endpoint -i
> >
> > it includes in the response headers:
> >
> > xyz: whatever
> >
> > I know I have the option of adding a processor with:
> >
> > exchange.getIn().removeHeaders("*");
> >
> > However it seems to me very non-intuitive that any HTTP headers sent
> > by the client might be echoed back by default. There are potential
> > security concerns if for example, the Authorization header is sent
> > back to the client. I'm just wondering if this issue came up before or
> > if we would consider changing the default behaviour?
> >
> > Thanks,
> >
> > Colm.
>
>
>
> --
> Zoran Regvart
