F is for Fonts - Security? or Missing the Point

Following industry standards? That’s an F.

Using Content Distribution Networks (CDNs) and new technologies to get resources like fonts to clients is the standard industry practice recommended by the likes of Google and other tech giants to give users the best possible experience. It speeds up how quickly your page loads and allows your browser to cache commonly used technologies.

We use Google Fonts on our website, or at least we did before today, because that was Google’s recommendation. It meant that the fonts we used would load as quickly as possible, and users browsers would only request information required rather than exhaustive font information.

Our clients use automated security monitoring platforms to judge us on what they can see of our servers and public websites, so we do too! Unfortunately, recently, the platform we use decided that following Google’s guidance on fonts was completely unacceptable and downgraded our score to an F.

That score, for our website used primarily for marketing, would definitely invalidate us as a vendor to many companies if they were doing their “due diligence” at that point in time.

There is a Point … Kinda

Using remotely hosted website resources as an attack vector can and has occurred in industry, so it is a risk to be mindful of. BUT, we need to look at the source. Is it hosted on a trustworthy CDN? Or is it elsewhere that has less or no trust?

It’s similar to trusting software: are we going to trust software from some sketchy website? Or are we going to trust software from Google’s App store. Running any software could compromise our computer, but the source matters.

I remember years ago that a developer had a problem with a VERY high traffic website deep linking to his Javascript library that he hosted himself. It was causing problems with the huge amount of traffic it was sending to his site, so he got in touch to ask them to simply host it themselves. They stupidly refused. That then gave him full control over their website. So, he released a new version, that would only be served when linked/ run from their website, that replaced all images on their domain with pictures of cats. They quickly resolved the situation and hopefully learnt a lesson.

So while it is a theoretical security risk, the context matters deeply.

Risk Management Isn’t Just Automation

Risk Management standards have long-established that risks have two key factors: Consequence and Likelihood, to come up with a final score on how severe the risk is. We can’t just automate away the context of the risk.

Let’s assess our situation.

What is the consequence of a malicious font being downloaded to our clients? Well it’s not code like Javascript so that makes it harder to exploit. However, if there’s an unpatched vulnerability in Chrome or Firefox for how fonts are handled, it could cause a compromise of a large number of client computers. Let’s assume it’s a “4 - major impact”. It’s not going to catastrophically take down the internet or businesses, but it’s serious enough.

Now what would you peg the likelihood of Google’s font servers getting hacked AND there being a bug at that time that could cause this risk event to occur? This is a “cherries need to line up” type situation so the likelihood would need to be very low. I would say google having a major security incident on a font server would have to be a “1 - rare”, so even if it was “2 - unlikely” to have a critical failure in the browser (happened ~4 times in the last decade), we’re looking at an event that is likely to never occur given this context.

So with our usual risk management processes, we’d consider if there’s anything else we can reasonably do without causing problems. Given it’s a 1, there’s not much more we could do short of elimination - don’t follow industry standards and make the user experience worse for those visiting our sites.

In any event, if Google had servers hacked in a meaningful way, it’d be catastrophic for the entire internet … not just those using fonts.

The Real Problem

Relying on automation of security auditing that ignores context is incredibly dangerous. It’s far more risky to link to a poorly maintained source than a trusted leader like Google. Context for risks matters.

Unfortunately a lot of company boards and senior management are relying on these style of reports. They are gaining a false sense of security or insecurity about vendors.

I’ve dealt with too many major vendors who had major security flaws in their products that were never addressed during my time with those products, but would not be detected by these systems. Malicious or ill-informed users that click on every link they find, share passwords, or have poor cybersecurity hygiene are a huge risk to organisations. Not Google Fonts.

I put very little trust in automated security reports. They rarely seem to examine context properly and are more akin to a “tick and flick” risk assessment where it’s not done seriously and adds zero real safety. They’re great for finding obvious flaws that need no nuance, but beyond that they end up creating issues.

For instance, we run our own servers and are constantly deducted points on automated tools just for doing so. We’ve had to point out serious flaws in numerous “false positives” where they were claiming we had major security flaws when our servers were all patched and up to date. According to them, running a mail server is a “bad thing”, but I’m not sure Google would appreciate us using Gmail for testing our email notifications are working properly at high volumes!

I worked in risk management for many years as my introduction to the mining industry. I also have a solid basis in cybersecurity. Given that, I find this type of approach to managing cybersecurity risks particularly frustrating and a waste of my time and that of my team.

The Solution

Use these automated tools, but stop putting too much value in their output. It’s informative, not authoritative. They also have a vested interest to be noisy about minor issues to try to get your attention and demonstrate their value.

Engage with suppliers and clients proactively. Do they grab you as someone who understands real security, or is it more of a checklist item for them? The way you evaluate your providers should change if they’re a technology provider or a civil contractor.

We love having technical discussions on our security practices with those that are interested. Feel free to reach out! If enough people are interested we are happy to run an online talk about security and devfu’s approaches to key risk factors.

What did we do in the end? We manually embedded the fonts in our website. It will now make our website load a little slower for our users. Sorry about that, but the security gods had spoken, and we wouldn’t want the Board Members of a large mining company to think poorly of us over some linked fonts designed to make things run more smoothly.