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 <an.delb...@gmail.com> 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. <insert blurb about licensing etc> > > " > > > > 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, > > > >>> 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 > > > >>> <emond.papega...@gmail.com> 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 > > > >>>> <emond.papega...@gmail.com> 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 > > > > > > > > -- > > Become a Wicket expert, learn from the best: http://wicketinaction.com > > > > > -- > Andrea Del Bene. > Apache Wicket committer.
