Re: CSP in Wicket 9
Hi Ernesto, On Tue, Jan 21, 2020 at 10:30 PM Ernesto Reinaldo Barreiro < reier...@gmail.com> wrote: > IMHO more than marketing it is important not to lose/disrupt customers and > people that has been using wicket for MANY years. Even less when 9.x has > been waiting to be released for quite some time. e.g. for my current > customer I've been keeping a branch of application that is 9.x. A few > months ago there was a tlak that 9,x will be out sooner than later, I > haven't updated that branch for a while now. I'm afraid is some disruptives > changes are rolled out now this will discourage people to migrate. I > haven't been following development of CSP in detail, but if there exists > the risk that this will brake existing applications, at this stage of > releasing 9.x, I would say leave it for 10.x > I don't expect big issues for the users due to CSP. If there are errors in the browser console related to CSP then it is one line change in YourApplication#init() to disable it and move on. > > On Tue, Jan 21, 2020 at 10:10 PM Emond Papegaaij < > emond.papega...@gmail.com> > wrote: > > > In my opinion marketing is very important, but I think it is more > > important to have this option enabled on as many applications as > > possible. Enabling this by default will give this a much wider reach > > than just having it available. Most importantly, it will be enabled on > > new applications, guiding the developer into making a more secure > > application. If it is not enabled by default, I doubt many developers > > will enable it on their new application. For that you have to look > > into the guide, see that it's available and then enable it. > > > > For existing applications, I think many will either disable it or at > > least configure CSP to be less strict. But still, if this triggers > > just a few to make their application work with CSP, I'd consider that > > a win. > > > > IMHO as developers of a popular web framework it is our duty to work > > on a secure internet and push these features actively. > > > > Emond > > > > On Tue, Jan 21, 2020 at 3:07 PM Andrea Del Bene > > wrote: > > > > > > I agree with the marketable value of CSP but I don't think it will lose > > > appeal if we make it disabled by default. As I said, I agree to > > eventually > > > enable it by default, but I don't think the time is ripe yet. > > > > > > On Tue, Jan 21, 2020 at 2:27 PM Martijn Dashorst < > > martijn.dasho...@gmail.com> > > > wrote: > > > > > > > Not sure if enabling it by default is a bad thing when you can, as > per > > > > migration guide, disable it with one statement in your > > > > WebApplication#init(). > > > > > > > > Also, when looking at marketable features, having CSP, and enabled by > > > > default, is something that publications will take notice of. Just > like > > > > being Jakarta EE prepared: > > > > > > > > "Deliver Secure Future Proof Web Applications with Apache Wicket 9 > > > > > > > > Apache Wicket 9 delivers Content Security Policy (CSP) protection > > > > out-of-the-box, protecting web applications against a variety of web > > > > based attack vectors. CSP is a cross-browser technology that prevents > > > > several attacks on web applications by limiting the > > > > > > > > With the adoption of the Jakarta EE standards, Apache Wicket 9 is one > > > > of the first Java frameworks prepared for the new future of > enterprise > > > > Java. > > > > " > > > > > > > > Martijn > > > > > > > > On Tue, Jan 21, 2020 at 2:00 PM Andrea Del Bene < > an.delb...@gmail.com> > > > > wrote: > > > > > > > > > > IMHO forcing users to adopt a new potential breaking feature is a > > > > > mistake. We should wait for a wider interest in CSP to enable it by > > > > > default. Don't get me wrong, I'm not underestimating the importance > > of > > > > > this feature which is a fantastic tool to ensure security. > > Nonetheless, > > > > > I believe that forcing users to comply with it will only have the > > effect > > > > > of upsetting them. > > > > > > > > > > On 1/21/20 1:27 PM, Emond Papegaaij wrote: > > > > > > On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov < > > mgrigo...@apache.org> > > > > wrote: > > > > > >> On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij < > > > > emond.papega...@gmail.com> > > > > > >> wrote: > > > > > >> > > > > > >>> I've discussed this with our unit manager, and got permission > to > > > > > >>> donate our CSP code to Wicket. I think a strong, out of the box > > CSP > > > > is > > > > > >>> a killer feature to have for Wicket 9. Not many frameworks can > > match > > > > > >>> this. For this, I would like to continue working on the > following > > > > > >>> parts: > > > > > >>> * Remove all inline styling and JS from Wicket. I will need > some > > help > > > > > >>> with this, especially the Form related code. > > > > > >>> * Make sure all examples work find with a strong CSP enabled > > > > > >>> * Add the CSP code to Wicket and provide several presets > (strong, > > > > > >>>
Re: CSP in Wicket 9
On Tue, Jan 21, 2020 at 10:10 PM Emond Papegaaij wrote: > In my opinion marketing is very important, but I think it is more > important to have this option enabled on as many applications as > possible. Enabling this by default will give this a much wider reach > than just having it available. Most importantly, it will be enabled on > new applications, guiding the developer into making a more secure > application. If it is not enabled by default, I doubt many developers > will enable it on their new application. For that you have to look > into the guide, see that it's available and then enable it. > We can also enable it by default in the quickstart archetype. > > For existing applications, I think many will either disable it or at > least configure CSP to be less strict. But still, if this triggers > just a few to make their application work with CSP, I'd consider that > a win. > I agree! Fixing runtime errors is harder than compilation ones. We just need to explain well how to make CSP less strict and how to disable it both in the migration guide and the user guide. > > IMHO as developers of a popular web framework it is our duty to work > on a secure internet and push these features actively. > > Emond > > On Tue, Jan 21, 2020 at 3:07 PM Andrea Del Bene > wrote: > > > > I agree with the marketable value of CSP but I don't think it will lose > > appeal if we make it disabled by default. As I said, I agree to > eventually > > enable it by default, but I don't think the time is ripe yet. > > > > On Tue, Jan 21, 2020 at 2:27 PM Martijn Dashorst < > martijn.dasho...@gmail.com> > > wrote: > > > > > Not sure if enabling it by default is a bad thing when you can, as per > > > migration guide, disable it with one statement in your > > > WebApplication#init(). > > > > > > Also, when looking at marketable features, having CSP, and enabled by > > > default, is something that publications will take notice of. Just like > > > being Jakarta EE prepared: > > > > > > "Deliver Secure Future Proof Web Applications with Apache Wicket 9 > > > > > > Apache Wicket 9 delivers Content Security Policy (CSP) protection > > > out-of-the-box, protecting web applications against a variety of web > > > based attack vectors. CSP is a cross-browser technology that prevents > > > several attacks on web applications by limiting the > > > > > > With the adoption of the Jakarta EE standards, Apache Wicket 9 is one > > > of the first Java frameworks prepared for the new future of enterprise > > > Java. > > > " > > > > > > Martijn > > > > > > On Tue, Jan 21, 2020 at 2:00 PM Andrea Del Bene > > > wrote: > > > > > > > > IMHO forcing users to adopt a new potential breaking feature is a > > > > mistake. We should wait for a wider interest in CSP to enable it by > > > > default. Don't get me wrong, I'm not underestimating the importance > of > > > > this feature which is a fantastic tool to ensure security. > Nonetheless, > > > > I believe that forcing users to comply with it will only have the > effect > > > > of upsetting them. > > > > > > > > On 1/21/20 1:27 PM, Emond Papegaaij wrote: > > > > > On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov < > mgrigo...@apache.org> > > > wrote: > > > > >> On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij < > > > emond.papega...@gmail.com> > > > > >> wrote: > > > > >> > > > > >>> I've discussed this with our unit manager, and got permission to > > > > >>> donate our CSP code to Wicket. I think a strong, out of the box > CSP > > > is > > > > >>> a killer feature to have for Wicket 9. Not many frameworks can > match > > > > >>> this. For this, I would like to continue working on the following > > > > >>> parts: > > > > >>> * Remove all inline styling and JS from Wicket. I will need some > help > > > > >>> with this, especially the Form related code. > > > > >>> * Make sure all examples work find with a strong CSP enabled > > > > >>> * Add the CSP code to Wicket and provide several presets (strong, > > > > >>> unsafeJsAndStyling, reportOnly, disabled) > > > > >>> * Enable CSP with the strong preset by default > > > > >>> > > > > >> I think this will break all applications which migrate from > earlier > > > version. > > > > >> I like that Wicket will be more secure by default but > > > > >> 1) most people do not really care about CSP (yet) > > > > >> 2) last time when I tested CSP it was behaving differently on > > > different > > > > >> browsers. I hope it is better now since only Firefox is not based > on > > > > >> Chromium. According to https://caniuse.com/#search=csp IE11 > might be > > > > >> problematic. > > > > >> > > > > >> Whatever we choose as default we should document how to switch it > on > > > and > > > > >> off. > > > > >> The user guide needs to be updated! > > > > >> > > > > > Yes, enabling a strict CSP will probably break all existing > > > > > applications on upgrade. But the upgrade will do that anyway (I > had to > > > > > fix quite a few compilation errors to get my app
Re: CSP in Wicket 9
IMHO more than marketing it is important not to lose/disrupt customers and people that has been using wicket for MANY years. Even less when 9.x has been waiting to be released for quite some time. e.g. for my current customer I've been keeping a branch of application that is 9.x. A few months ago there was a tlak that 9,x will be out sooner than later, I haven't updated that branch for a while now. I'm afraid is some disruptives changes are rolled out now this will discourage people to migrate. I haven't been following development of CSP in detail, but if there exists the risk that this will brake existing applications, at this stage of releasing 9.x, I would say leave it for 10.x On Tue, Jan 21, 2020 at 10:10 PM Emond Papegaaij wrote: > In my opinion marketing is very important, but I think it is more > important to have this option enabled on as many applications as > possible. Enabling this by default will give this a much wider reach > than just having it available. Most importantly, it will be enabled on > new applications, guiding the developer into making a more secure > application. If it is not enabled by default, I doubt many developers > will enable it on their new application. For that you have to look > into the guide, see that it's available and then enable it. > > For existing applications, I think many will either disable it or at > least configure CSP to be less strict. But still, if this triggers > just a few to make their application work with CSP, I'd consider that > a win. > > IMHO as developers of a popular web framework it is our duty to work > on a secure internet and push these features actively. > > Emond > > On Tue, Jan 21, 2020 at 3:07 PM Andrea Del Bene > wrote: > > > > I agree with the marketable value of CSP but I don't think it will lose > > appeal if we make it disabled by default. As I said, I agree to > eventually > > enable it by default, but I don't think the time is ripe yet. > > > > On Tue, Jan 21, 2020 at 2:27 PM Martijn Dashorst < > martijn.dasho...@gmail.com> > > wrote: > > > > > Not sure if enabling it by default is a bad thing when you can, as per > > > migration guide, disable it with one statement in your > > > WebApplication#init(). > > > > > > Also, when looking at marketable features, having CSP, and enabled by > > > default, is something that publications will take notice of. Just like > > > being Jakarta EE prepared: > > > > > > "Deliver Secure Future Proof Web Applications with Apache Wicket 9 > > > > > > Apache Wicket 9 delivers Content Security Policy (CSP) protection > > > out-of-the-box, protecting web applications against a variety of web > > > based attack vectors. CSP is a cross-browser technology that prevents > > > several attacks on web applications by limiting the > > > > > > With the adoption of the Jakarta EE standards, Apache Wicket 9 is one > > > of the first Java frameworks prepared for the new future of enterprise > > > Java. > > > " > > > > > > Martijn > > > > > > On Tue, Jan 21, 2020 at 2:00 PM Andrea Del Bene > > > wrote: > > > > > > > > IMHO forcing users to adopt a new potential breaking feature is a > > > > mistake. We should wait for a wider interest in CSP to enable it by > > > > default. Don't get me wrong, I'm not underestimating the importance > of > > > > this feature which is a fantastic tool to ensure security. > Nonetheless, > > > > I believe that forcing users to comply with it will only have the > effect > > > > of upsetting them. > > > > > > > > On 1/21/20 1:27 PM, Emond Papegaaij wrote: > > > > > On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov < > mgrigo...@apache.org> > > > wrote: > > > > >> On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij < > > > emond.papega...@gmail.com> > > > > >> wrote: > > > > >> > > > > >>> I've discussed this with our unit manager, and got permission to > > > > >>> donate our CSP code to Wicket. I think a strong, out of the box > CSP > > > is > > > > >>> a killer feature to have for Wicket 9. Not many frameworks can > match > > > > >>> this. For this, I would like to continue working on the following > > > > >>> parts: > > > > >>> * Remove all inline styling and JS from Wicket. I will need some > help > > > > >>> with this, especially the Form related code. > > > > >>> * Make sure all examples work find with a strong CSP enabled > > > > >>> * Add the CSP code to Wicket and provide several presets (strong, > > > > >>> unsafeJsAndStyling, reportOnly, disabled) > > > > >>> * Enable CSP with the strong preset by default > > > > >>> > > > > >> I think this will break all applications which migrate from > earlier > > > version. > > > > >> I like that Wicket will be more secure by default but > > > > >> 1) most people do not really care about CSP (yet) > > > > >> 2) last time when I tested CSP it was behaving differently on > > > different > > > > >> browsers. I hope it is better now since only Firefox is not based > on > > > > >> Chromium. According to https://caniuse.com/#search=csp
Re: CSP in Wicket 9
In my opinion marketing is very important, but I think it is more important to have this option enabled on as many applications as possible. Enabling this by default will give this a much wider reach than just having it available. Most importantly, it will be enabled on new applications, guiding the developer into making a more secure application. If it is not enabled by default, I doubt many developers will enable it on their new application. For that you have to look into the guide, see that it's available and then enable it. For existing applications, I think many will either disable it or at least configure CSP to be less strict. But still, if this triggers just a few to make their application work with CSP, I'd consider that a win. IMHO as developers of a popular web framework it is our duty to work on a secure internet and push these features actively. Emond On Tue, Jan 21, 2020 at 3:07 PM Andrea Del Bene wrote: > > I agree with the marketable value of CSP but I don't think it will lose > appeal if we make it disabled by default. As I said, I agree to eventually > enable it by default, but I don't think the time is ripe yet. > > On Tue, Jan 21, 2020 at 2:27 PM Martijn Dashorst > wrote: > > > Not sure if enabling it by default is a bad thing when you can, as per > > migration guide, disable it with one statement in your > > WebApplication#init(). > > > > Also, when looking at marketable features, having CSP, and enabled by > > default, is something that publications will take notice of. Just like > > being Jakarta EE prepared: > > > > "Deliver Secure Future Proof Web Applications with Apache Wicket 9 > > > > Apache Wicket 9 delivers Content Security Policy (CSP) protection > > out-of-the-box, protecting web applications against a variety of web > > based attack vectors. CSP is a cross-browser technology that prevents > > several attacks on web applications by limiting the > > > > With the adoption of the Jakarta EE standards, Apache Wicket 9 is one > > of the first Java frameworks prepared for the new future of enterprise > > Java. > > " > > > > Martijn > > > > On Tue, Jan 21, 2020 at 2:00 PM Andrea Del Bene > > wrote: > > > > > > IMHO forcing users to adopt a new potential breaking feature is a > > > mistake. We should wait for a wider interest in CSP to enable it by > > > default. Don't get me wrong, I'm not underestimating the importance of > > > this feature which is a fantastic tool to ensure security. Nonetheless, > > > I believe that forcing users to comply with it will only have the effect > > > of upsetting them. > > > > > > On 1/21/20 1:27 PM, Emond Papegaaij wrote: > > > > On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov > > wrote: > > > >> On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij < > > emond.papega...@gmail.com> > > > >> wrote: > > > >> > > > >>> I've discussed this with our unit manager, and got permission to > > > >>> donate our CSP code to Wicket. I think a strong, out of the box CSP > > is > > > >>> a killer feature to have for Wicket 9. Not many frameworks can match > > > >>> this. For this, I would like to continue working on the following > > > >>> parts: > > > >>> * Remove all inline styling and JS from Wicket. I will need some help > > > >>> with this, especially the Form related code. > > > >>> * Make sure all examples work find with a strong CSP enabled > > > >>> * Add the CSP code to Wicket and provide several presets (strong, > > > >>> unsafeJsAndStyling, reportOnly, disabled) > > > >>> * Enable CSP with the strong preset by default > > > >>> > > > >> I think this will break all applications which migrate from earlier > > version. > > > >> I like that Wicket will be more secure by default but > > > >> 1) most people do not really care about CSP (yet) > > > >> 2) last time when I tested CSP it was behaving differently on > > different > > > >> browsers. I hope it is better now since only Firefox is not based on > > > >> Chromium. According to https://caniuse.com/#search=csp IE11 might be > > > >> problematic. > > > >> > > > >> Whatever we choose as default we should document how to switch it on > > and > > > >> off. > > > >> The user guide needs to be updated! > > > >> > > > > Yes, enabling a strict CSP will probably break all existing > > > > applications on upgrade. But the upgrade will do that anyway (I had to > > > > fix quite a few compilation errors to get my app starting again). We > > > > do have to document this in the migration guide. Switching to an > > > > unsafe CSP or disabling it entirely is just one line of code. That's a > > > > lot less work than fixing the compilation errors. I hope enabling CSP > > > > by default will make more people aware of this browser feature. At > > > > Topicus we intent to fix our applications to work with the strict CSP, > > > > probably not directly after migrating to 9, but Wicket 9 is a good > > > > push in this direction. > > > > > > > > It is true that support is lacking for some browsers. A browser that >
Re: CSP in Wicket 9
I agree with the marketable value of CSP but I don't think it will lose appeal if we make it disabled by default. As I said, I agree to eventually enable it by default, but I don't think the time is ripe yet. On Tue, Jan 21, 2020 at 2:27 PM Martijn Dashorst wrote: > Not sure if enabling it by default is a bad thing when you can, as per > migration guide, disable it with one statement in your > WebApplication#init(). > > Also, when looking at marketable features, having CSP, and enabled by > default, is something that publications will take notice of. Just like > being Jakarta EE prepared: > > "Deliver Secure Future Proof Web Applications with Apache Wicket 9 > > Apache Wicket 9 delivers Content Security Policy (CSP) protection > out-of-the-box, protecting web applications against a variety of web > based attack vectors. CSP is a cross-browser technology that prevents > several attacks on web applications by limiting the > > With the adoption of the Jakarta EE standards, Apache Wicket 9 is one > of the first Java frameworks prepared for the new future of enterprise > Java. > " > > Martijn > > On Tue, Jan 21, 2020 at 2:00 PM Andrea Del Bene > wrote: > > > > IMHO forcing users to adopt a new potential breaking feature is a > > mistake. We should wait for a wider interest in CSP to enable it by > > default. Don't get me wrong, I'm not underestimating the importance of > > this feature which is a fantastic tool to ensure security. Nonetheless, > > I believe that forcing users to comply with it will only have the effect > > of upsetting them. > > > > On 1/21/20 1:27 PM, Emond Papegaaij wrote: > > > On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov > wrote: > > >> On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij < > emond.papega...@gmail.com> > > >> wrote: > > >> > > >>> I've discussed this with our unit manager, and got permission to > > >>> donate our CSP code to Wicket. I think a strong, out of the box CSP > is > > >>> a killer feature to have for Wicket 9. Not many frameworks can match > > >>> this. For this, I would like to continue working on the following > > >>> parts: > > >>> * Remove all inline styling and JS from Wicket. I will need some help > > >>> with this, especially the Form related code. > > >>> * Make sure all examples work find with a strong CSP enabled > > >>> * Add the CSP code to Wicket and provide several presets (strong, > > >>> unsafeJsAndStyling, reportOnly, disabled) > > >>> * Enable CSP with the strong preset by default > > >>> > > >> I think this will break all applications which migrate from earlier > version. > > >> I like that Wicket will be more secure by default but > > >> 1) most people do not really care about CSP (yet) > > >> 2) last time when I tested CSP it was behaving differently on > different > > >> browsers. I hope it is better now since only Firefox is not based on > > >> Chromium. According to https://caniuse.com/#search=csp IE11 might be > > >> problematic. > > >> > > >> Whatever we choose as default we should document how to switch it on > and > > >> off. > > >> The user guide needs to be updated! > > >> > > > Yes, enabling a strict CSP will probably break all existing > > > applications on upgrade. But the upgrade will do that anyway (I had to > > > fix quite a few compilation errors to get my app starting again). We > > > do have to document this in the migration guide. Switching to an > > > unsafe CSP or disabling it entirely is just one line of code. That's a > > > lot less work than fixing the compilation errors. I hope enabling CSP > > > by default will make more people aware of this browser feature. At > > > Topicus we intent to fix our applications to work with the strict CSP, > > > probably not directly after migrating to 9, but Wicket 9 is a good > > > push in this direction. > > > > > > It is true that support is lacking for some browsers. A browser that > > > does not support CSP at all (like IE11) is not hindered by it either. > > > It becomes more problematic when a browser does not support the > > > directives used (like strict-dynamic). This might cause issues and we > > > need to test that and change the CSP to make sure it works in those > > > browsers as well. IMHO as a framework it is our job to set an example > > > and show how we think this is done best. When a user thinks the gained > > > security is not worth the pain, he/she can disable it and hope for the > > > best. > > > > > > Best regards, > > > Emond > > > > > >>> I've already started the work on the 'csp' branch. On this branch, > > >>> I've also migrated all but the servlet API to the jakarta namespace. > > >>> > > >>> Best regards, > > >>> Emond > > >>> > > >>> On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij > > >>> wrote: > > Searching through our Jira, I've found WICKET-6687, filed by Andrew. > > He already pinpointed several places that break with a strict CSP > > enabled. I'm going to convert that bug into a task (we do not have > > epic) and
Re: CSP in Wicket 9
Not sure if enabling it by default is a bad thing when you can, as per migration guide, disable it with one statement in your WebApplication#init(). Also, when looking at marketable features, having CSP, and enabled by default, is something that publications will take notice of. Just like being Jakarta EE prepared: "Deliver Secure Future Proof Web Applications with Apache Wicket 9 Apache Wicket 9 delivers Content Security Policy (CSP) protection out-of-the-box, protecting web applications against a variety of web based attack vectors. CSP is a cross-browser technology that prevents several attacks on web applications by limiting the With the adoption of the Jakarta EE standards, Apache Wicket 9 is one of the first Java frameworks prepared for the new future of enterprise Java. " Martijn On Tue, Jan 21, 2020 at 2:00 PM Andrea Del Bene wrote: > > IMHO forcing users to adopt a new potential breaking feature is a > mistake. We should wait for a wider interest in CSP to enable it by > default. Don't get me wrong, I'm not underestimating the importance of > this feature which is a fantastic tool to ensure security. Nonetheless, > I believe that forcing users to comply with it will only have the effect > of upsetting them. > > On 1/21/20 1:27 PM, Emond Papegaaij wrote: > > On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov > > wrote: > >> On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij > >> > >> wrote: > >> > >>> I've discussed this with our unit manager, and got permission to > >>> donate our CSP code to Wicket. I think a strong, out of the box CSP is > >>> a killer feature to have for Wicket 9. Not many frameworks can match > >>> this. For this, I would like to continue working on the following > >>> parts: > >>> * Remove all inline styling and JS from Wicket. I will need some help > >>> with this, especially the Form related code. > >>> * Make sure all examples work find with a strong CSP enabled > >>> * Add the CSP code to Wicket and provide several presets (strong, > >>> unsafeJsAndStyling, reportOnly, disabled) > >>> * Enable CSP with the strong preset by default > >>> > >> I think this will break all applications which migrate from earlier > >> version. > >> I like that Wicket will be more secure by default but > >> 1) most people do not really care about CSP (yet) > >> 2) last time when I tested CSP it was behaving differently on different > >> browsers. I hope it is better now since only Firefox is not based on > >> Chromium. According to https://caniuse.com/#search=csp IE11 might be > >> problematic. > >> > >> Whatever we choose as default we should document how to switch it on and > >> off. > >> The user guide needs to be updated! > >> > > Yes, enabling a strict CSP will probably break all existing > > applications on upgrade. But the upgrade will do that anyway (I had to > > fix quite a few compilation errors to get my app starting again). We > > do have to document this in the migration guide. Switching to an > > unsafe CSP or disabling it entirely is just one line of code. That's a > > lot less work than fixing the compilation errors. I hope enabling CSP > > by default will make more people aware of this browser feature. At > > Topicus we intent to fix our applications to work with the strict CSP, > > probably not directly after migrating to 9, but Wicket 9 is a good > > push in this direction. > > > > It is true that support is lacking for some browsers. A browser that > > does not support CSP at all (like IE11) is not hindered by it either. > > It becomes more problematic when a browser does not support the > > directives used (like strict-dynamic). This might cause issues and we > > need to test that and change the CSP to make sure it works in those > > browsers as well. IMHO as a framework it is our job to set an example > > and show how we think this is done best. When a user thinks the gained > > security is not worth the pain, he/she can disable it and hope for the > > best. > > > > Best regards, > > Emond > > > >>> I've already started the work on the 'csp' branch. On this branch, > >>> I've also migrated all but the servlet API to the jakarta namespace. > >>> > >>> Best regards, > >>> Emond > >>> > >>> On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij > >>> wrote: > Searching through our Jira, I've found WICKET-6687, filed by Andrew. > He already pinpointed several places that break with a strict CSP > enabled. I'm going to convert that bug into a task (we do not have > epic) and create new bugs for all issues in that ticket. That should > make it easier to track progress. > > Best regards, > Emond > > On Sat, Jan 11, 2020 at 10:31 PM Emond Papegaaij > wrote: > > Hi all, > > > > For the past few days I've been experimenting with the new CSP > > features in Wicket 9. I really want to thank Andrew, Sven and Martin > > for the great work you guys did in making this possible. I'm getting > > very
Re: CSP in Wicket 9
I do agree with Andrea. I think it's better to have to add one line of code to enable the feature, than the opposite... Or better, it can be a flag like development/deployment. This way we can issue a warning at startup, same kind of warning when we are running on development mode... We can also promote the feature in the migration guide, and on the website
Re: CSP in Wicket 9
We are not forcing uses to comply with a strict CSP when we enable it by default. It's just a setting, which can be turned off with a single line of code that will be put in the migration guide. Enabling this by default will however protect new applications out of the box and raise the awareness of this feature. Our examples can serve as a guide on how to use this. Emond On Tue, Jan 21, 2020 at 2:00 PM Andrea Del Bene wrote: > > IMHO forcing users to adopt a new potential breaking feature is a > mistake. We should wait for a wider interest in CSP to enable it by > default. Don't get me wrong, I'm not underestimating the importance of > this feature which is a fantastic tool to ensure security. Nonetheless, > I believe that forcing users to comply with it will only have the effect > of upsetting them. > > On 1/21/20 1:27 PM, Emond Papegaaij wrote: > > On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov > > wrote: > >> On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij > >> > >> wrote: > >> > >>> I've discussed this with our unit manager, and got permission to > >>> donate our CSP code to Wicket. I think a strong, out of the box CSP is > >>> a killer feature to have for Wicket 9. Not many frameworks can match > >>> this. For this, I would like to continue working on the following > >>> parts: > >>> * Remove all inline styling and JS from Wicket. I will need some help > >>> with this, especially the Form related code. > >>> * Make sure all examples work find with a strong CSP enabled > >>> * Add the CSP code to Wicket and provide several presets (strong, > >>> unsafeJsAndStyling, reportOnly, disabled) > >>> * Enable CSP with the strong preset by default > >>> > >> I think this will break all applications which migrate from earlier > >> version. > >> I like that Wicket will be more secure by default but > >> 1) most people do not really care about CSP (yet) > >> 2) last time when I tested CSP it was behaving differently on different > >> browsers. I hope it is better now since only Firefox is not based on > >> Chromium. According to https://caniuse.com/#search=csp IE11 might be > >> problematic. > >> > >> Whatever we choose as default we should document how to switch it on and > >> off. > >> The user guide needs to be updated! > >> > > Yes, enabling a strict CSP will probably break all existing > > applications on upgrade. But the upgrade will do that anyway (I had to > > fix quite a few compilation errors to get my app starting again). We > > do have to document this in the migration guide. Switching to an > > unsafe CSP or disabling it entirely is just one line of code. That's a > > lot less work than fixing the compilation errors. I hope enabling CSP > > by default will make more people aware of this browser feature. At > > Topicus we intent to fix our applications to work with the strict CSP, > > probably not directly after migrating to 9, but Wicket 9 is a good > > push in this direction. > > > > It is true that support is lacking for some browsers. A browser that > > does not support CSP at all (like IE11) is not hindered by it either. > > It becomes more problematic when a browser does not support the > > directives used (like strict-dynamic). This might cause issues and we > > need to test that and change the CSP to make sure it works in those > > browsers as well. IMHO as a framework it is our job to set an example > > and show how we think this is done best. When a user thinks the gained > > security is not worth the pain, he/she can disable it and hope for the > > best. > > > > Best regards, > > Emond > > > >>> I've already started the work on the 'csp' branch. On this branch, > >>> I've also migrated all but the servlet API to the jakarta namespace. > >>> > >>> Best regards, > >>> Emond > >>> > >>> On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij > >>> wrote: > Searching through our Jira, I've found WICKET-6687, filed by Andrew. > He already pinpointed several places that break with a strict CSP > enabled. I'm going to convert that bug into a task (we do not have > epic) and create new bugs for all issues in that ticket. That should > make it easier to track progress. > > Best regards, > Emond > > On Sat, Jan 11, 2020 at 10:31 PM Emond Papegaaij > wrote: > > Hi all, > > > > For the past few days I've been experimenting with the new CSP > > features in Wicket 9. I really want to thank Andrew, Sven and Martin > > for the great work you guys did in making this possible. I'm getting > > very close to running my application with a very tight and secure CSP. > > Unfortunately, some parts of Wicket still use inline styling and > > scripting. So far I've found the following two issues: > > > > * hidden components with setOutputMarkupPlaceholderTag(true) have > >>> display:none > > * Forms render inline styling and javascript in some cases to improve > > submit handling > > > > I think we
Re: CSP in Wicket 9
IMHO forcing users to adopt a new potential breaking feature is a mistake. We should wait for a wider interest in CSP to enable it by default. Don't get me wrong, I'm not underestimating the importance of this feature which is a fantastic tool to ensure security. Nonetheless, I believe that forcing users to comply with it will only have the effect of upsetting them. On 1/21/20 1:27 PM, Emond Papegaaij wrote: On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov wrote: On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij wrote: I've discussed this with our unit manager, and got permission to donate our CSP code to Wicket. I think a strong, out of the box CSP is a killer feature to have for Wicket 9. Not many frameworks can match this. For this, I would like to continue working on the following parts: * Remove all inline styling and JS from Wicket. I will need some help with this, especially the Form related code. * Make sure all examples work find with a strong CSP enabled * Add the CSP code to Wicket and provide several presets (strong, unsafeJsAndStyling, reportOnly, disabled) * Enable CSP with the strong preset by default I think this will break all applications which migrate from earlier version. I like that Wicket will be more secure by default but 1) most people do not really care about CSP (yet) 2) last time when I tested CSP it was behaving differently on different browsers. I hope it is better now since only Firefox is not based on Chromium. According to https://caniuse.com/#search=csp IE11 might be problematic. Whatever we choose as default we should document how to switch it on and off. The user guide needs to be updated! Yes, enabling a strict CSP will probably break all existing applications on upgrade. But the upgrade will do that anyway (I had to fix quite a few compilation errors to get my app starting again). We do have to document this in the migration guide. Switching to an unsafe CSP or disabling it entirely is just one line of code. That's a lot less work than fixing the compilation errors. I hope enabling CSP by default will make more people aware of this browser feature. At Topicus we intent to fix our applications to work with the strict CSP, probably not directly after migrating to 9, but Wicket 9 is a good push in this direction. It is true that support is lacking for some browsers. A browser that does not support CSP at all (like IE11) is not hindered by it either. It becomes more problematic when a browser does not support the directives used (like strict-dynamic). This might cause issues and we need to test that and change the CSP to make sure it works in those browsers as well. IMHO as a framework it is our job to set an example and show how we think this is done best. When a user thinks the gained security is not worth the pain, he/she can disable it and hope for the best. Best regards, Emond I've already started the work on the 'csp' branch. On this branch, I've also migrated all but the servlet API to the jakarta namespace. Best regards, Emond On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij wrote: Searching through our Jira, I've found WICKET-6687, filed by Andrew. He already pinpointed several places that break with a strict CSP enabled. I'm going to convert that bug into a task (we do not have epic) and create new bugs for all issues in that ticket. That should make it easier to track progress. Best regards, Emond On Sat, Jan 11, 2020 at 10:31 PM Emond Papegaaij wrote: Hi all, For the past few days I've been experimenting with the new CSP features in Wicket 9. I really want to thank Andrew, Sven and Martin for the great work you guys did in making this possible. I'm getting very close to running my application with a very tight and secure CSP. Unfortunately, some parts of Wicket still use inline styling and scripting. So far I've found the following two issues: * hidden components with setOutputMarkupPlaceholderTag(true) have display:none * Forms render inline styling and javascript in some cases to improve submit handling I think we should try to fix these before Wicket 9 is released. I will continue to debug our application to see if there are more places. At Topicus we wrote a IRequestCycleListener that applies the CSP automatically to every request via HTTP headers. The API makes it easy to configure the CSP. I've added support for the nonce as well. It uses a new nonce for every request, which should be more secure than a nonce bound to a session. I'll discuss with my employee next week if we can donate this code to Wicket. Best regards, Emond
Re: CSP in Wicket 9
On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov wrote: > > On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij > wrote: > > > I've discussed this with our unit manager, and got permission to > > donate our CSP code to Wicket. I think a strong, out of the box CSP is > > a killer feature to have for Wicket 9. Not many frameworks can match > > this. For this, I would like to continue working on the following > > parts: > > * Remove all inline styling and JS from Wicket. I will need some help > > with this, especially the Form related code. > > * Make sure all examples work find with a strong CSP enabled > > * Add the CSP code to Wicket and provide several presets (strong, > > unsafeJsAndStyling, reportOnly, disabled) > > * Enable CSP with the strong preset by default > > > > I think this will break all applications which migrate from earlier version. > I like that Wicket will be more secure by default but > 1) most people do not really care about CSP (yet) > 2) last time when I tested CSP it was behaving differently on different > browsers. I hope it is better now since only Firefox is not based on > Chromium. According to https://caniuse.com/#search=csp IE11 might be > problematic. > > Whatever we choose as default we should document how to switch it on and > off. > The user guide needs to be updated! > Yes, enabling a strict CSP will probably break all existing applications on upgrade. But the upgrade will do that anyway (I had to fix quite a few compilation errors to get my app starting again). We do have to document this in the migration guide. Switching to an unsafe CSP or disabling it entirely is just one line of code. That's a lot less work than fixing the compilation errors. I hope enabling CSP by default will make more people aware of this browser feature. At Topicus we intent to fix our applications to work with the strict CSP, probably not directly after migrating to 9, but Wicket 9 is a good push in this direction. It is true that support is lacking for some browsers. A browser that does not support CSP at all (like IE11) is not hindered by it either. It becomes more problematic when a browser does not support the directives used (like strict-dynamic). This might cause issues and we need to test that and change the CSP to make sure it works in those browsers as well. IMHO as a framework it is our job to set an example and show how we think this is done best. When a user thinks the gained security is not worth the pain, he/she can disable it and hope for the best. Best regards, Emond > > > > I've already started the work on the 'csp' branch. On this branch, > > I've also migrated all but the servlet API to the jakarta namespace. > > > > Best regards, > > Emond > > > > On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij > > wrote: > > > > > > Searching through our Jira, I've found WICKET-6687, filed by Andrew. > > > He already pinpointed several places that break with a strict CSP > > > enabled. I'm going to convert that bug into a task (we do not have > > > epic) and create new bugs for all issues in that ticket. That should > > > make it easier to track progress. > > > > > > Best regards, > > > Emond > > > > > > On Sat, Jan 11, 2020 at 10:31 PM Emond Papegaaij > > > wrote: > > > > > > > > Hi all, > > > > > > > > For the past few days I've been experimenting with the new CSP > > > > features in Wicket 9. I really want to thank Andrew, Sven and Martin > > > > for the great work you guys did in making this possible. I'm getting > > > > very close to running my application with a very tight and secure CSP. > > > > Unfortunately, some parts of Wicket still use inline styling and > > > > scripting. So far I've found the following two issues: > > > > > > > > * hidden components with setOutputMarkupPlaceholderTag(true) have > > display:none > > > > * Forms render inline styling and javascript in some cases to improve > > > > submit handling > > > > > > > > I think we should try to fix these before Wicket 9 is released. I will > > > > continue to debug our application to see if there are more places. > > > > > > > > At Topicus we wrote a IRequestCycleListener that applies the CSP > > > > automatically to every request via HTTP headers. The API makes it easy > > > > to configure the CSP. I've added support for the nonce as well. It > > > > uses a new nonce for every request, which should be more secure than a > > > > nonce bound to a session. I'll discuss with my employee next week if > > > > we can donate this code to Wicket. > > > > > > > > Best regards, > > > > Emond > >
Re: CSP in Wicket 9
On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij wrote: > I've discussed this with our unit manager, and got permission to > donate our CSP code to Wicket. I think a strong, out of the box CSP is > a killer feature to have for Wicket 9. Not many frameworks can match > this. For this, I would like to continue working on the following > parts: > * Remove all inline styling and JS from Wicket. I will need some help > with this, especially the Form related code. > * Make sure all examples work find with a strong CSP enabled > * Add the CSP code to Wicket and provide several presets (strong, > unsafeJsAndStyling, reportOnly, disabled) > * Enable CSP with the strong preset by default > I think this will break all applications which migrate from earlier version. I like that Wicket will be more secure by default but 1) most people do not really care about CSP (yet) 2) last time when I tested CSP it was behaving differently on different browsers. I hope it is better now since only Firefox is not based on Chromium. According to https://caniuse.com/#search=csp IE11 might be problematic. Whatever we choose as default we should document how to switch it on and off. The user guide needs to be updated! > > I've already started the work on the 'csp' branch. On this branch, > I've also migrated all but the servlet API to the jakarta namespace. > > Best regards, > Emond > > On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij > wrote: > > > > Searching through our Jira, I've found WICKET-6687, filed by Andrew. > > He already pinpointed several places that break with a strict CSP > > enabled. I'm going to convert that bug into a task (we do not have > > epic) and create new bugs for all issues in that ticket. That should > > make it easier to track progress. > > > > Best regards, > > Emond > > > > On Sat, Jan 11, 2020 at 10:31 PM Emond Papegaaij > > wrote: > > > > > > Hi all, > > > > > > For the past few days I've been experimenting with the new CSP > > > features in Wicket 9. I really want to thank Andrew, Sven and Martin > > > for the great work you guys did in making this possible. I'm getting > > > very close to running my application with a very tight and secure CSP. > > > Unfortunately, some parts of Wicket still use inline styling and > > > scripting. So far I've found the following two issues: > > > > > > * hidden components with setOutputMarkupPlaceholderTag(true) have > display:none > > > * Forms render inline styling and javascript in some cases to improve > > > submit handling > > > > > > I think we should try to fix these before Wicket 9 is released. I will > > > continue to debug our application to see if there are more places. > > > > > > At Topicus we wrote a IRequestCycleListener that applies the CSP > > > automatically to every request via HTTP headers. The API makes it easy > > > to configure the CSP. I've added support for the nonce as well. It > > > uses a new nonce for every request, which should be more secure than a > > > nonce bound to a session. I'll discuss with my employee next week if > > > we can donate this code to Wicket. > > > > > > Best regards, > > > Emond >
Re: CSP in Wicket 9
I've discussed this with our unit manager, and got permission to donate our CSP code to Wicket. I think a strong, out of the box CSP is a killer feature to have for Wicket 9. Not many frameworks can match this. For this, I would like to continue working on the following parts: * Remove all inline styling and JS from Wicket. I will need some help with this, especially the Form related code. * Make sure all examples work find with a strong CSP enabled * Add the CSP code to Wicket and provide several presets (strong, unsafeJsAndStyling, reportOnly, disabled) * Enable CSP with the strong preset by default I've already started the work on the 'csp' branch. On this branch, I've also migrated all but the servlet API to the jakarta namespace. Best regards, Emond On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij wrote: > > Searching through our Jira, I've found WICKET-6687, filed by Andrew. > He already pinpointed several places that break with a strict CSP > enabled. I'm going to convert that bug into a task (we do not have > epic) and create new bugs for all issues in that ticket. That should > make it easier to track progress. > > Best regards, > Emond > > On Sat, Jan 11, 2020 at 10:31 PM Emond Papegaaij > wrote: > > > > Hi all, > > > > For the past few days I've been experimenting with the new CSP > > features in Wicket 9. I really want to thank Andrew, Sven and Martin > > for the great work you guys did in making this possible. I'm getting > > very close to running my application with a very tight and secure CSP. > > Unfortunately, some parts of Wicket still use inline styling and > > scripting. So far I've found the following two issues: > > > > * hidden components with setOutputMarkupPlaceholderTag(true) have > > display:none > > * Forms render inline styling and javascript in some cases to improve > > submit handling > > > > I think we should try to fix these before Wicket 9 is released. I will > > continue to debug our application to see if there are more places. > > > > At Topicus we wrote a IRequestCycleListener that applies the CSP > > automatically to every request via HTTP headers. The API makes it easy > > to configure the CSP. I've added support for the nonce as well. It > > uses a new nonce for every request, which should be more secure than a > > nonce bound to a session. I'll discuss with my employee next week if > > we can donate this code to Wicket. > > > > Best regards, > > Emond
Re: CSP in Wicket 9
Searching through our Jira, I've found WICKET-6687, filed by Andrew. He already pinpointed several places that break with a strict CSP enabled. I'm going to convert that bug into a task (we do not have epic) and create new bugs for all issues in that ticket. That should make it easier to track progress. Best regards, Emond On Sat, Jan 11, 2020 at 10:31 PM Emond Papegaaij wrote: > > Hi all, > > For the past few days I've been experimenting with the new CSP > features in Wicket 9. I really want to thank Andrew, Sven and Martin > for the great work you guys did in making this possible. I'm getting > very close to running my application with a very tight and secure CSP. > Unfortunately, some parts of Wicket still use inline styling and > scripting. So far I've found the following two issues: > > * hidden components with setOutputMarkupPlaceholderTag(true) have display:none > * Forms render inline styling and javascript in some cases to improve > submit handling > > I think we should try to fix these before Wicket 9 is released. I will > continue to debug our application to see if there are more places. > > At Topicus we wrote a IRequestCycleListener that applies the CSP > automatically to every request via HTTP headers. The API makes it easy > to configure the CSP. I've added support for the nonce as well. It > uses a new nonce for every request, which should be more secure than a > nonce bound to a session. I'll discuss with my employee next week if > we can donate this code to Wicket. > > Best regards, > Emond
