5 ms·
Resend Security Incident
- sikan_ 3y agoDatabase credentials in the dashboard..? How?
- sgarman 3y agoThey say so much in their article but never dive into how this happened, seems like the most important part? User error? Configuration error?
- josevalerio 3y agoProbably all the new NextJS / Server Components stuff - mixing and matching server & client code in the same file. Or the classic NEXT_PUBLIC_ env var
- dimfeld 3y agoI have no inside info, but it sounds like the key was inadvertently bundled into the client-side code. This could happen when using web frameworks that do both client-side and server-side rendering, if one of your client-side files imports something from a file that is supposed to be server-only, and contains the API key environment variable. Some frameworks automatically detect this and fail to build if you do it, but apparently not all of them.
- laborcontract 3y agoLike my sibling said, probably as a next_public environmental variable. They probably were doing fetch requests for the dashboard client side. I wonder if they had the entire db url stored as a next_public_db_url. If that’s really irresponsible, and pretty easy to catch in development, at least for the pages router stuff. Maybe a little less so obvious for ssr pages. I haven’t tried a lot of the new app_router, maybe there’s a lot more mixing of client and server side stuff there. Regardless, you should be auditing your environmental variables!
- sikan_ 3y agoRSC seems like a massive foot gun - given that you can accidentally bundle anything from the server.
- h1fra 3y agoMaybe it was a Supabase or Firebase credentials ?
- scottydelta 3y agoAs an early user of resend, found it to be easy to use than all the other providers but now I have lost confidence in resend(our clients' emails being hacked is a deal breaker) and will be deactivating multiple paid resend accounts and move to other big players. The root cause of this incident is so noobish. It's hard to believe that bad actors were even able to access the production dB directly even if the credentials were leaked. Production dB should never be accessible to anyone other than the app accessing it.
- goenning 3y agoThey probably use serverless database where VPC is an enterprise feature
- ko_pivot 3y agoThe way I read the incident post, it almost feels like they aren't talking about the actual `postgres://` uri but some other secret that provides database access indirectly, maybe a backend API that uses a single secret key. I could be wrong, but you'd think the incident report would just say "we leaked the connection string for our internet-reachable database" if that were the case.