Security as an afterthought

The Browser Company that makes the Arc browser had a massive security hole that potentially allowed anyone with a bit of skill to execute arbitrary code in your browser.

Massive oops. Here’s what happened.

Arc enables you to write your own CSS/JS to customize and apply to a website through a feature called Boosts.

These Boosts are then synced between all your Arc installations using Firebase.

However, the Firebase ACL rules that Arc implemented allowed you to modify the creatorID that uniquely identifies you to that of another user, meaning you could upload any JS/CSS that you want to whomever you targeted and have it run on their side.

All you needed to know was your target’s user ID which is not that hard to get.

They said that no one got hacked (according to their logs), and the hole was promptly patched, but it reveals a deeper issue.

The thing is…

I see too often that security is an afterthought. We need to start seeing it as a fundamental aspect of product quality instead.

Plenty of people jumped on Arc, not just for the tab management but also because “Arc is built from the ground up to be private and secure.”

If security is a feature, you need to invest in security.

Independently audit the code and infrastructure.

Have an incident response strategy.

Penetration test it.

But perhaps the best remedy is to treat security as part of the culture you are building.

At the end of the day, security is not a one-time thing you do.

It’s built layer after layer from the code, infrastructure, education, and processes.

The tricky part is that if you do a good job, no one will applaud you for the security incident that you didn’t have, but that’s the ultimate goal.

Yours,

Taj