Last week, the ARK web browser experienced its first catastrophic vulnerability, where a hacker could gain access to your browser to execute CSS and JavaScript on any website, almost like Godmode cross-site scripting. That means an attacker could log your passwords, track your browser history, insert fake news into your favorite websites, and all sorts of other bad things with the power of JavaScript. What's even more crazy, though, is that all this could be accomplished without the end user ever visiting a malicious website. That's horrifying if you're an ARK user, but the good news is that this issue has been patched and nobody got exploited.
The big question, though, is how could something so catastrophic happen to a product which itself is based on the highly secure Chromium browser engine? Well, the root cause comes down to misconfigured security rules on my favorite big-ass backend, Firebase. In today's video, we'll find out how ARK narrowly avoided an iceberg, and who to point fingers at and blame for this issue. It is October 4th, 2024, and you're watching The Code Report. On its website, Arc claims to be the Chrome replacement you've been waiting for, built from the ground up to be private and secure.
If you haven't used it yet, Arc is a very cool browser that's popular among programmers because it allows you to organize tabs on the side, has a bunch of good built-in shortcuts, and has this thing that feels like the command palette in VS Code. Under the hood, it's built on top of the Chromium browser engine, with a nice smooth front-end UI written in Swift. However, its claim of being private and secure has just been put to the ultimate test. Luckily, the exploit was found by a good guy named XYZ3VA, who reported it to the browser company, and to their credit, took immediate action and fixed it the next day. Now, in order to explain the exploit, we first need to understand a feature called boosts in the Arc. browser.
Basically, it's a feature that allows you to customize any website with your own CSS and JavaScript. Like if you hated developers'design choices on a website, you can remix and customize it, and then you can even share those adjustments with your friends. Although it's worth noting that custom JavaScript can't be shared because it would be too easy to exploit. That's a good idea, but here's the thing.
If you use the Arc browser, you likely use it on multiple devices. And that means if you want to use your boost across multiple devices, Arc needs to store your executable JavaScript code on its backend. And it does that with Google's Firebase and Cloud Firestore database. Upon hearing that, the Firebase haters out there will immediately want to point the finger at Firebase.
But here's what actually happened. When you log in with Firebase, it generates a user ID. You can then store custom user data in a JSON-like format by writing data to Firestore, which is a NoSQL document database, kind of like MongoDB. where a document in a collection has the same ID as the user who owns it.
What's unique about Firestore, though, is that you can query it directly from client-side code. But before you ship to production, it's essential that you have solid security rules in place, which are defined in a custom DSL called Firestore Rules. This is great for getting things done quickly, but its Achilles heel is that it can be susceptible to misconfiguration.
In this case, when you create a boost on ARC, it stores that data in a collection called Boosts, which has a field for creator ID that points back to the user who owns it. What the security researcher found out is that you don't have access to boosts for other users. However, you do have the ability to change the user ID on your own boost to the user ID of another user. That means if Bob knows Alice's user ID, he could write a boost that does something horrible, like intercept a query for directions on Google Maps, then use some JavaScript to replace the results with directions to Diddy's mansion.
Now, the ability to change a user ID on a document might be desired behavior, like when a user can assign data to another user, but on Arc it's storing executable code, so allowing a user to change the creator ID was a massive fail on Arc's part. A possible fix could be accomplished with one-line and Firestore security rules that disallows updates to the creator ID if the authentication user ID doesn't match. The blame falls entirely on Arc in this case, and this failure is totally egregious and unacceptable.
It's an issue I teach about in my Firebase 101 courses, and it's absurd to think that a company building a browser would make such an amateur mistake. It's on par with committing an API key to a public Git repo. Say what you will about Firebase, but their only crime here was making security rules so easy to implement that the developer got lazy. And what's funny is that Arc is... is switching off Firebase now, which feels like an attempt to deflect some of the blame, but the bottom line is that Firebase is a good boy and didn't do nothing wrong.
The only thing we learned is something we already know, that your security logic needs to be well-tested and bulletproof, especially if you're storing executable code. But Firebase is not the only comprehensive user management platform. An excellent alternative is Clerk, the sponsor of today's video.
It provides an out-of-the-box user authentication solution with the highest standards and security compliance to keep your customer data safe. As a developer, you'll have access to every possible sign-in method you could imagine, including highly secure modern strategies like biometric passkeys and multi-factor auth. What's really awesome, though, is its suite of pre-built UI elements that seamlessly integrate into any front-end code.
You can drop them in as React components or use them as an unstyled starting point that can be fully customized. Then, as users start pouring in, you can manage them with the backend dashboard and integrate them into other services with webhooks. In fact, end-users can even manage their own data and security preferences on a fully hosted profile page.
Give Clerk a try for free today using the link in the description. This has been The Code Report. Thanks for watching, and I will see you in the next one.