Issue 69: Data Breach at Vercel. The Target Was 'Login with Google' – Security Measures You Should Review Immediately

Vercel has recently become an indispensable infrastructure for web developers. Shocking news broke recently that unauthorized access to Vercel's internal systems occurred, leading to the leakage of environment variables and API keys for some users.

While this is an incident that many engineers and developers might consider a 'could happen to me' scenario, the most important point to focus on is 'how they got in.' The starting point was the exploitation of the commonly used 'Login with Google' feature.

What happened in the Vercel incident?

In this incident, Vercel's internal systems were accessed without authorization, and environment variables and API keys for some customers were exfiltrated. The affected data consisted of environment variables that were not set to 'Sensitive' and were stored in a recoverable state on the system.

However, what is truly terrifying about this incident is that Vercel's own vulnerabilities were not directly exploited. The attack began with the compromise of a third-party service called 'Context.ai'.

Leakage of OAuth tokens

A Vercel employee had signed up for Context.ai using 'Login with Google.' At that time, they had granted the third-party app extremely powerful permissions, specifically 'Allow All'.

Account takeover

The attackers compromised Context.ai and stole this employee's OAuth token. They used it to gain unauthorized access to the employee's Google Workspace.

Reaching internal systems

Using the hijacked Google account as a stepping stone, the attackers infiltrated Vercel's internal systems.

This is a classic example of a chain-reaction supply chain attack, where a robust system was breached through a single 'ant-sized hole'.

Why is 'Login with Google' dangerous?

When using a new web service, 'Login with Google' (OAuth authentication) is convenient because it saves you the trouble of thinking up a password. Most people likely use it almost unconsciously.

But that convenience is the biggest trap. When the authentication screen displays, 'This app is requesting access to your Google account,' do you click 'Allow' without reading the details carefully?

For simple login integration, it usually only requires 'viewing email address and profile information.' However, some services may request excessive permissions, such as 'reading, sending, and deleting Gmail' or 'viewing and editing all files in Google Drive'.

In this incident as well, the Vercel employee had granted 'Allow All' access. If you give strong permissions to a third-party app with weak security, the moment the token is leaked, that Google account becomes a foothold for attackers. If they can snoop on your emails, they could even bypass password resets for other services.

In other words, granting permissions via 'Login with Google' is an act that should be treated with as much caution as handing over a spare key to your house.

Concrete measures you can take starting today

Taking this incident as a lesson, here are the measures you should take immediately, categorized for 'individuals' and 'organizations'.

◆ For Individuals (Developers and General Users)

1. Immediately revoke unnecessary connections

The most reliable measure is to audit the permissions of apps you have connected in the past and left unattended. You can check your Google account settings by following the steps below.

Simply performing this check periodically will significantly reduce your risk.

2. Think before granting permissions

Whenever you use 'Sign in with Google' in the future, you should always read the list of requested permissions. If a service asks for 'Read Gmail' or 'Edit Drive' access when it should only be handling a simple login, it should be treated with caution.

In such cases, it is safer to skip using the service or switch to direct registration via email instead of using Google integration.

3. Vercel users should review environment variables

If you operate web services on Vercel, you need to review your environment variable settings. You should always ensure that the 'Sensitive' setting is turned on for confidential information such as API keys.

If you have important keys that were previously operated with this setting turned off, you should perform a rotation just to be safe. Reissue new keys and invalidate the old ones. Even if this task is tedious, it is better not to put it off.

◆ For Organizations (Google Workspace Administrators)

If your company uses Google Workspace, there are limits to relying on the individual literacy of employees. Administrators should open 'API controls' from the Google Workspace admin console and restrict access permissions for third-party apps across the entire domain.

Whitelist only trusted apps and prevent employees from granting strong permissions to external apps on their own. It is essential to change the design so that dangerous permissions, such as full access to Gmail or Drive, cannot be granted based on individual judgment.

Summary

The recent Vercel incident demonstrated that a single connection error can escalate into a major disaster that shakes a company's core systems.

Recent cyberattacks are becoming faster and more sophisticated through the use of AI. The time lag between token leakage and actual unauthorized use continues to shorten, and there are increasing situations where 'responding after noticing an anomaly' is no longer fast enough. What is needed now is a stance of eliminating risks before an anomaly is even detected.

'Sign in with Google' is an excellent feature that greatly enhances the developer experience and daily convenience. However, what is being exchanged behind the scenes is not just login information, but 'permissions' themselves. Do not underestimate the weight of this.

Once you finish reading this article, please go ahead and open your Google account security settings screen to check your connected apps. Those five minutes will become a defensive line that protects both you and your services.