Chrome's New Cookie Protection and the Week Microsoft's Cloud Security Got Roasted

Page content

Chrome’s New Cookie Protection and the Week Microsoft’s Cloud Security Got Roasted

You know that feeling when you’re explaining to users why they can’t just click “remember me” on every website? Well, Google just made our lives a little easier with Chrome 146’s new Device Bound Session Credentials (DBSC) protection. But before we celebrate, let’s talk about the broader security picture this week – because it’s been a mixed bag.

The new DBSC feature in Chrome 146 is actually pretty clever. Instead of just storing session cookies that any malware can grab and replay, Chrome now ties these credentials to the specific device. Think of it as adding a hardware fingerprint to your authentication tokens.

Here’s why this matters: we’ve all seen those incident reports where an infostealer grabbed someone’s session cookies, and suddenly the attacker is logged into their Gmail, banking, or corporate apps without ever needing passwords. DBSC makes those stolen cookies useless because they’re cryptographically bound to the original device.

The implementation is Windows-only for now, which makes sense given that’s where most infostealers operate. But I’m curious to see how this affects our user experience monitoring – will we start seeing more “please log in again” prompts when users switch devices?

Google’s API Key Problem: A Developer Nightmare

Speaking of Google, they’ve got another issue brewing. Security researchers found that dozens of Android apps are shipping with exposed API keys that give unauthorized access to Gemini endpoints.

This is the classic “secrets in code” problem that we’ve been fighting for years, but with an AI twist. Developers are hardcoding their Gemini API keys directly into Android apps, and anyone with basic reverse engineering skills can extract them. Once you have those keys, you’ve got access to the full Gemini API – potentially racking up costs or accessing sensitive data.

It’s a reminder that our secure development training needs to keep up with new technologies. The same principles apply whether it’s database credentials or AI API keys: never hardcode secrets, use proper key management, and assume your compiled code will be reverse engineered.

Shadow AI: The New Shadow IT

The shadow AI phenomenon feels eerily familiar to those of us who lived through the early days of cloud adoption. Remember when marketing was spinning up their own AWS accounts because IT was “too slow”? Well, now employees are plugging company data into ChatGPT, Claude, and dozens of other AI tools we’ve never heard of.

The productivity gains are real – I’ve seen developers cut debugging time in half with AI assistance. But from a security perspective, we’re flying blind. What data is being processed? Where are these AI models hosted? What’s the data retention policy?

I think we need to get ahead of this one. Rather than playing whack-a-mole with AI tools, we should be establishing approved AI platforms and clear usage policies. The alternative is discovering that your entire codebase got uploaded to some random AI service during a “productivity experiment.”

Microsoft’s Cloud Security Under Fire

And then there’s Microsoft. Bruce Schneier highlighted a ProPublica report showing that federal cybersecurity evaluators basically threw up their hands trying to assess Microsoft’s cloud security. The government reviewers couldn’t get proper documentation and expressed “lack of confidence” in the overall security posture.

This hits close to home because so many of us are running critical infrastructure on Azure and Microsoft 365. When the federal government’s security experts can’t get straight answers about how Microsoft protects our data, what chance do we have during our vendor assessments?

The timing is particularly awkward given Microsoft’s recent security incidents and their push for more government cloud contracts. It raises uncomfortable questions about whether we’re putting too many eggs in one very large, but apparently poorly documented, basket.

The Persistent Threat of Targeted Campaigns

Finally, researchers traced a Middle East spear-phishing campaign back to the Bitter APT group, which has South Asian origins. These targeted campaigns remind us that while we’re dealing with cookie theft and API key exposure, nation-state actors are still running sophisticated, persistent operations.

The attribution work here is particularly interesting because it shows how threat actors are expanding their geographical focus. Bitter traditionally targeted South Asian entities, but this campaign spread across the Middle East throughout 2023 and 2024.

What This Means for Us

This week’s news reinforces a few key themes. First, browser security is evolving in response to real threats – Chrome’s DBSC feature shows that major vendors are taking session hijacking seriously. Second, new technologies like AI are creating old problems in new forms, and we need to adapt our policies accordingly.

Most importantly, the Microsoft documentation issues highlight something we all know but don’t always act on: vendor security assessments matter, even for the biggest names in the industry. Just because everyone uses a service doesn’t mean its security is transparent or adequate.

Sources