High Risk or High Maintenance? An Update on Magento 2 Security
As Magento 2 was released in 2015, developers and merchants were not only introduced to a completely new codebase, but also a new way of working with Magento, from strict policies to gain access to the Magento marketplace for extension builders to working with version updates rather than security-only patches for system integrators. The latter was commented on often by the Magento community, claiming that Magento 2 shops became more vulnerable than Magento 1 shops, and the call for security-only patches grew louder and louder over time.
With the release of Magento 2.3.3, on Oct. 8, 2019, Magento answered this need by introducing security-only patches for Magento 2. Did this improve the security of Magento 2 shops, or are merchants (and their customers) still at risk? Does the community see security as a costly necessity or as rather inferior in comparison to cool new features?
Security Is a Pain Point
Magento 1 has had a long history of security patches, making it relatively easy to keep this open-source framework safe for merchants and their clients to use. This didn’t mean that security patches were immediately implemented after their release, though. At my company, which services over 2,500 Magento shops, we noticed a lot of our clients were running on old, unsafe Magento versions or had not implemented security patches long after these had been released.
When we asked our system integrator (SI) partners about this, we heard many times that security was the responsibility of the merchant, and if the merchants didn’t want to allocate budget to security patches or updates, this was their risk to take. We argued that, as an SI, you don’t want your name on outdated or unsafe code, but SI partners told us that visible changes to the design or new features in a shop were often prioritized by merchants over security updates, leaving the SI no choice but to forego necessary security patches. The lack of visibility of security became apparent, and we decided to take action to reward SI partners who valued and prioritized security of their clients.
Certified Security
The security of a webshop begins with a secure hosting environment, but to guarantee a safe shopping experience for customers, the application (Magento) running on the hosting platform needs to be updated and patched regularly as well. We work together with our SI partners in a certification program where we, among others, check the security of the shops under their customer account. Quickly after the introduction of this certification program, we saw major improvements in the security of the web shops maintained by our SI partners: Over 80% of their Magento 1 shops were up to date and had implemented security patches within four weeks after their release.
New Challenges With Magento 2
In the early days of Magento 2, however, because security updates were included in version updates, you needed to update the entire code to implement security fixes, which is time-consuming and costly. Moreover, these new versions often contained new features the clients didn’t necessarily need nor wanted to pay for. We noticed the percentage of shops running on a safe Magento 2 version dropped significantly. To illustrate this: Four weeks after the release of security versions 2.1.15 and 2.2.6, 15% of the shops on our platform had been updated to Magento 2.1.15, and only 3% had been updated to Magento 2.2.6. We received many complaints from our SI partners that our standards for the Hypernode certification needed to be lowered for Magento 2 compared to Magento 1, as it was impossible to update Magento 2 shops within four weeks after a new version was released, both because of time and because of financial constraints.
Patches Remain the Holy Grail?
Magento recognized this difficulty in keeping their application safe and therefore introduced security-only patches for Magento 2 with the release of Magento 2.3.3. This meant that instead of updating the entire code, you could suffice with implementing the security patch, which typically only affects a quarter to a third of the code, thereby severely cutting time and costs. One would expect that this would lead to better update percentages of shops on our platform, and it did: 26% of the Magento 2 shops on our platform have implemented the latest security patch, while a staggering 45% of the shops maintained by our Hypernode certified partners are up to date. A big improvement indeed! However, compared to the update percentages of Magento 1 shops, this number is still relatively low. Even though patches seem to make it easier to ensure the security of Magento 2 shops, apparently other factors are in play that complicate this as compared to Magento 1.
Variation = Complexity
When talking with our SI partners, we quickly learn that each agency has their own way of working with Magento and their clients. Some compel their clients to always upgrade to the latest Magento version; others leave the choice to the client. Mike de Landgraaf from Dutch Magento agency MDL Online told us he can more or less predict how many hours per year he needs for Magento updates and can therefore give a pretty accurate cost estimate to his clients. The problem comes with extensions: If these need to be updated as well, it’s difficult to foresee how much work this will be, and he therefore needs to bill these hours afterwards. The more extensions you use, the more complex — and therefore more costly — the upgrade will be.
Peter Jaap Blaakmeer, Magento master and owner of Elgentos, adds that when an upgrade contains a new module, this requires less testing than when it contains an update of an existing feature. Therefore, each upgrade has different complications and makes it difficult to plan ahead. Ruthger Idema from Guapa explains that sometimes, when a new version becomes available, clients are eager to upgrade to this version and benefit from new features and are less keen to implement a security patch for their current version. The upgrade to Magento 2.3 would, for instance, be more interesting than implementing a security patch for Magento 2.2 but might take longer because this is a lot of work. In the meantime, their 2.2 is unsafe.
The upgrade to Magento 2.3 would, for instance, be more interesting than implementing a security patch for Magento 2.2 but might take longer because this is a lot of work. In the meantime, their 2.2 is unsafe.
Magento 2.3 seems to be better with security patches than the previous versions, acknowledge both Yannick Röling from Experius and Bas Rozema from MediaCT. Upgrading from 2.0 to 2.1, from 2.1 to 2.2 and from 2.2 to 2.3 required major changes and a lot of work. 2.3 seems to be quite stable and really only provides security patches, while before you had to do a more costly regular upgrade, including both security patches and new features, says Wesley van der Stel from ISM e-Company. In general, new version releases four times per year is quite a lot, and not every client is willing to provide the budget needed to keep up, though this is strongly recommended if you are a MediaCT client. Peter Jaap explains that if a customer is not willing to upgrade, the security patches do make it easier to convince clients to at least implement these.
In conclusion, we can say the release of security-only patches did improve the security of Magento 2 shops in general. Although the first security patches also included new functionalities, thereby (unnecessarily) complicating their implementation, the latest P2 patch for Magento 2.3.4 seems relatively easy to implement and is thereby improving the security of shops running on this version before upgrading to Magento 2.3.5. However, with the current pace of new version releases (four times per year), it’s tempting for merchants to skip one or more versions and do a bigger upgrade every now and then to reduce costs.
Security-only patches can be relatively easy and therefore cheap to implement, but merchants might still prefer waiting until they can upgrade to a new version with cool new features, work with too many extensions and custom code to justify the costs, or simply not see the need for security updates until they are confronted with an actual security breach. This shows the implementation of security patches is still largely dependent on the willingness, budget and time of the merchant. Some SIs compel their clients to always upgrade to the latest Magento version or always (at least) implement security patches, while others leave it to the clients to decide if and how they want to spend their budget, reasoning it’s their risk and responsibility to take.
