I've changed the code. From what I can see, the header is now only set once per request. It could be there some exceptions to this, for example when the request is restarted during rendering. IMHO that's not a big issue, because the header is still added only once.
I've also added a demo-case to the CSP example that shows that CSP protection still works in ajax requests. Best regards, Emond On Fri, Mar 13, 2020 at 9:18 AM Emond Papegaaij <emond.papega...@gmail.com> wrote: > > Hi Sven, > > I've reread the spec a bit more precise last night. I think we can > change the code to only set the header on a RenderPageRequestHandler. > The CSP is taken from the page and applies to all resources loaded by > that page. The only exceptions are child-contexts: iframes, objects > and js-workers. For iframes, Wicket will render a new page and thus > set the CSP. This only leaves objects and js-workers, which IMHO are > quite rare. I'm not sure if the child-context will inherit the CSP > from the page if it's not set. I couldn't find this in the spec. > > The reason to use a header is that it is the recommended method of > delivery for the CSP. The meta tag has some problems, for example when > resources show up before the tag. > > I'll give the above a try and see if it works. > > Best regards, > Emond > > On Thu, Mar 12, 2020 at 9:40 PM Sven Meier <s...@meiers.net> wrote: > > > > Hi Emond, > > > > for me setting the appropriate headers is part of rendering. > > > > I've just tried setting HTTP CSP headers from > > CSPNonceHeaderResponseDecorator, and that almost works (with minor > > changes to HtmlHeaderContainer, which currently doesn't allow setting of > > headers during rendering). > > > > Before you took over, CSPNonceHeaderResponseDecorator wrote the CSP > > headers in http-equiv <meta> tags. > > What was your reason to change this to HTTP headers in the first place? > > > > Regards > > Sven > > > > > > On 12.03.20 14:02, Emond Papegaaij wrote: > > > Hi Sven, > > > > > > Yes, you might be right. When rendering another page, normally the > > > header will be overridden when the second handler is resolved. > > > However, this will not happen when the page is not protected > > > (protectedPageFilter). Do you see a solution for this? Maybe recording > > > the desired action in the RequestCycle per handler, so the last > > > handler will always override the previous one? The action can then be > > > performed in onEndRequest. It would be nice if we had some tests for > > > this, but I'm not that experienced in writing tests with WicketTester > > > :) > > > > > > Setting the header on a resource usually doesn't make sense, but > > > doesn't hurt either. I haven't found a clear explanation of how CSP > > > values interact across requests. For example, for js you can use > > > strict-dynamic, but this doesn't apply to CSS, which breaks CSS loaded > > > via js. > > > > > > Best regards, > > > Emond > > > > > > On Thu, Mar 12, 2020 at 12:28 PM Sven Meier <s...@meiers.net> wrote: > > >> Hi Emond, > > >> > > >> it seems to me the CSPRequestCycleListener might add CSP headers > > >> prematurely. > > >> > > >> What if a request comes in for one page and another page is rendered in > > >> response? > > >> The listener will already add the headers when the request handler is > > >> resolved for the former page. > > >> > > >> What if the page streams back a resource? Setting the headers doesn't > > >> make sense then, does it? > > >> > > >> Sven > > >>
