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.
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.
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!
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.
