Resend Security Incident(resend.com)
resend.com
Resend Security Incident
https://resend.com/blog/incident-report-for-january-10-2024
10 comments
As 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.
They probably use serverless database where VPC is an enterprise feature
The 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.
Database credentials in the dashboard..? How?
RSC seems like a massive foot gun - given that you can accidentally bundle anything from the server.
Maybe it was a Supabase or Firebase credentials ?
They say so much in their article but never dive into how this happened, seems like the most important part? User error? Configuration error?
Probably all the new NextJS / Server Components stuff - mixing and matching server & client code in the same file. Or the classic NEXT_PUBLIC_ env var
I 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.
Some frameworks automatically detect this and fail to build if you do it, but apparently not all of them.
Like 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!
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!