Magento is one of the top eCommerce platforms in the world. It benefits both from closed-source development for its Enterprise Edition, and open-source development from its Community Edition.

Secure coding can only go so far. Patches can only be so timely. Here are some things to consider when working with Magento.

Isn’t Magento a secured platform?

Yes, Magento strives to be as secure as possible out of the box. Security is important to all open-source platforms, although it’s not always their first priority.

Unfortunately, ease of installation is often the victor when up against a security concern. Why? If you were concerned about security, you would naturally follow up after installation to secure the application. There are many sites out there that cover “Hardening Magento.” We wish Magento would follow the lead of WordPress and release an official guide.

I was promised Magento was secure.

One of the biggest draws to Magento installations is the low cost of entry to operating the platform. With the free Community Edition, many aspiring Web developers will offer to install, configure and theme your Magento instance at a low price.

Not all are bad at security, but the cheaper ones will be. Be sure that your developers have security chops when building your Magento instance.

Most important, this needs to be a relationship between yourself and your developer. If you are planning to use them once — or perhaps even once a quarter — just stop right there. Don’t do it.

You need a developer that is reviewing your site weekly, preferably daily, and sometimes more frequently than that.

There’s a reason Armor lives by this motto: “Don’t suck at patching!” Coined by Armor CSO Jeff Schilling, its effectiveness is derived from its simplicity. Poor patch monitoring and management can be attributed to the majority of security incidents we see.

I don’t store credit card data.

Most Magento owners have caught onto this message. Even if you never drop the credit card data to a database on your system, you may still be responsible for the transaction.

If a customer transmits their credit card data to your site and you, in turn, deliver that to a processor, you are probably responsible for protecting the data during that transaction.

A malicious actor won’t think twice about adding code to scrape the data as you receive it and offload it to his control servers. If you really want to offload the responsibility, look at utilizing “Magento Payment Bridge.”

I have security controls that will protect me.

This is great news! We always recommend practicing sound and proven security. In fact, we protect every server in our environment with battle-tested security controls.

Take notice, though. The bad guys are smart and are clever in their ability to adapt and evolve. The official Magento security blog offers insight, best practices and lessons learned from the latest attack methods.

While the advice is certainly spot on, we have found cases where the checks on their site are insufficient. Utilizing previous vulnerabilities, such as ShopLift, some actors are injecting JavaScript source references into the Magento database itself.

No matter how or where we attempt to scan the traffic, the credit card scrapping is occurring in customer browsers — with stolen data flowing directly to the threat actors — in a completely separate session. There are no security controls to monitor this at your Magento instance. Your developer would have to inspect the traffic and account for all external calls to find this behavior.

In the end, Magento requires constant vigilance by a security-minded developer, utilizing security controls and independent verification to be secured. Any organizations leveraging open-source platforms needs to be absolutely diligent in implementing and following a proper patch management program.