Is Electron a Security Risk?

Amid concerning news stories about Electron security vulnerabilities, many of our customers have wanted to know more about the potential threats and also understand why we use Electron at OpenFin. The bottom line (spoiler alert) is that the Electron threats are very real and anyone who tells you otherwise is doing you a massive disservice. Firms deploying Electron containers should invest in implementing a security model on top of Electron in the same way we have at OpenFin.

The Struggle Is Real

Let’s first dig into the question of whether the security threat is real. Last week we were dismayed to hear from a major bank that a vendor in the space had assured them that all of the Electron security vulnerabilities have been solved. This must have come as news to the Electron team since they provide this clear and lengthy disclaimer on their website.

“… be aware that displaying arbitrary content from untrusted sources poses a severe security risk that Electron is not intended to handle.”

Although Electron provides features to help developers mitigate security risks, this is left entirely in the hands of the application developer. In order to get comfortable with an application using Electron, every target customer would need to validate (at a minimum) that the 14 security points highlighted by the Electron team are being strictly followed. Since application developers are responsible for implementing the recommendations, customers would need to do that validation on every change or upgrade to both the Electron container as well as any content that is being loaded in the application.

Unfortunately, as this article explains, even apps that take these precautions are vulnerable.

“The programming blunder was highlighted and described in detail this month by TrustWave’s Brendan Scarvell. In short: the bug, CVE-2018-1000136, can be exploited to import arbitrary code into the application via Node.js.”

What are the kinds of apps most susceptible to these vulnerabilities? Any app or framework that uses Electron to provide access to 3rd party apps or content.

How OpenFin Solved This

Appreciating the threats from the beginning, our engineering team took three critical precautions when we decided to use Electron.

1. Reengineer the Chromium Security model into OpenFin.
2. Remove Node from the renderer process.
3. Do not expose any Electron API (private or public) to a third party app or website.

Putting the responsibility for implementing security controls in the hands of application developers is just too risky. Returning to a true web security architecture (which is secure by default) is a critical step for running web content on the desktop. At OpenFin, we have invested thousands of engineering hours over the past few years in maintaining this security as we’ve upgraded from one version of Chromium and Electron to the next. Developers who use Electron without making a similar investment are putting their end users at risk.

Why We Still Use It

So why do we use Electron despite the security vulnerabilities? We use it because Electron is a really terrific project. To not use it would be throwing the baby out with the bathwater. Electron provides base libraries that make accessing Chromium much easier and it does so elegantly (if insecurely). The project also has continued support and momentum from the tech community which means it is always getting better.

If you’re sitting at a security-sensitive desktop at a bank or buy-side firm, should you use an app or framework that runs on Electron? Absolutely not unless significant security precautions have been taken to lock down the very real current and future vulnerabilities.