Spelljacking: When your browser is too helpful

The enhanced spellchecking feature in some browsers may cause websites to send unencrypted sensitive data to online spellcheck services – including passwords. This sensitive data exposure vulnerability was originally reported in September 2022 and given the media-friendly name of spelljacking. While the highest-profile vulnerable sites have reportedly fixed the issue, spelljacking definitely deserves a second look as an example of security risks hiding among the complexity of benign features.

What is spelljacking?

Spelljacking occurs when your browser sends sensitive data entered on a website to an online spellchecking service. This can happen when you have enhanced spellchecking enabled in your browser (Google Chrome or Microsoft Edge), and the website or application doesn’t correctly exclude fields with sensitive data from spellchecking. When both conditions are met, your browser may send not only text you would normally want to spellcheck but also strings that should remain secret, such as login credentials or credit card numbers. And even if the site masks passwords as you enter them, they may still be sent when you use the Show password feature.

Unlike local spellchecking in the browser, which uses a language-specific dictionary installed on your computer, enhanced spellchecking works by sending the content of your text fields to a web service provided by the browser vendor. By enabling enhanced spellchecking, you are asking the browser to send everything you type to either Google or Microsoft for checking (depending on the browser) – and send it in plain text because each word needs to be looked up in a dictionary. While you might expect this to be done only for fields where spellchecking makes sense, it could happen for other fields as well, resulting in sensitive data exposure.

Why is spelljacking possible?

This vulnerability is a fascinating example of perfectly innocent features interacting in a complex and unexpected way. An online spellchecker is a natural companion to browser functionality such as search suggestions and autocompletion, with the added benefit that your browser doesn’t need to install and maintain a language-specific local dictionary. The main challenge is deciding what gets sent for checking and what doesn’t. With modern applications, sensitive data isn’t restricted to clearly labeled <input type="password"> form fields. Any <div> tag could potentially be an input field, and the browser has no reliable way of detecting this.

Ideally, web developers should specify the spellcheck=false attribute for every single text entry control that could include sensitive data. But using this attribute requires an extra step, complicates the code, and could degrade the user experience. And even assuming all intended places for entering sensitive data are covered, you could get users entering, for example, personally identifiable information in other fields that do get spellchecked.

Finally, the Show password feature that can allow password spelljacking is not only useful for making sure you haven’t mistyped your long and complex password – it can also be required for accessibility to work with screen readers. While a completely benign feature on its own, it could cause the browser to send your password in clear text as soon as you click Show password.

Is spelljacking a real threat?

To be clear, spelljacking is more a curiosity than an Internet-breaking issue or a widespread risk to personal data. For a start, even if your password is spelljacked, your browser is communicating with the provider’s API over HTTPS, so the unencrypted data is only known to your browser and the provider at the other end. Short of a man-in-the-middle attack, there’s no way for a third party to see your password, so there is no risk of standalone spelljacking attacks, at least not yet. (And if someone is eavesdropping on all your web traffic in a MITM situation, you have far bigger problems than spelljacking.)

The enhanced spellcheck feature is also disabled by default, so to risk spelljacking, you have to enable it manually, sometimes even dismissing a warning dialog. (In Chrome, the option lives under Settings > Sync and Google services and in many context menus.) And, of course, the website or application you’re using needs to code its input fields in a way that allows enhanced spellchecking to work even for sensitive data.

That said, there are still risks associated with this vulnerability, especially for compliance. Anyone using your site or application could potentially be sending sensitive business and personal data to either Google or Microsoft as they enter it into text fields. If all requirements for spelljacking are met, the browser vendor could be getting, for example, your employees’ company login credentials and other sensitive data sent in plain text to their spellchecking API. That’s hardly good information security practice, but it gets worse – if your site allows the browser to spellcheck personally identifiable information (PII), you could be on shaky legal grounds with personal data protection regulations.

It’s also safe to assume that spellcheck requests are somehow cached and logged both for performance (because spellchecking needs to work in close to real time) and to improve the dictionary. So after leaving the encrypted HTTPS channel, your passwords could well be stored in a server log somewhere, along with all the other unknown words. Again, maybe not an immediate threat but definitely a data leak that could lead to more serious issues down the line, including regulatory ones.

Security risks where you least expect them

While the initial research reported spelljacking vulnerabilities in several high-profile sites and applications, including password managers, most of these have been resolved. However, considering how unexpected the issue is, it’s likely thousands of websites and applications are still allowing browsers to relay login credentials and other user data to Google and Microsoft in plain text. Again, this is more a coincidence than a deliberate data grab – but not something anyone should be comfortable with.

There are several takeaways from this story. Firstly, any organization serious about data security may want to block the enhanced spellcheck feature in Chrome and Edge browsers on company-managed machines to prevent users from enabling it. Secondly, if you develop your own websites and applications, it’s a good idea to ensure you use spellcheck=false for all fields that accept any sort of sensitive data. And finally, whenever you see yet another useful web-enabled feature somewhere, ask yourself: Is this secure? Because in the current tangle of web technologies, a new vulnerability is never far away.