All the factors that contributed to this data being exposed could have been avoided.
First, user credentials for authenticating to another service shouldn’t be stored in plaintext, or even stored at all if possible. It’s typical for systems to use credentials to authenticate to a service, then receive an access token of some sort (e.g., a cookie or OAuth access token) in return. This token can be encrypted and stored instead of the user’s credentials, reducing the impact if exposed. If the service does not provide an API that does this, it may be necessary to authenticate using user credentials each time the system interacts with the service, although this is far from ideal. In this case, TeenSafe could have stored the credentials after encrypting them using an HSM-backed cryptographic key (e.g., AWS CloudHSM).
Second, administration/monitoring consoles such as Celery Flower should not be publicly accessible, especially without authentication. Ideally, TeenSafe would have used some form of firewall or AWS Elastic Load Balancer to restrict access to this portal, unless the visitor was accessing from a location internal to TeenSafe. Furthermore, a proxy can be configured to authenticate a user before providing access to data. There’s no reason that this data should have been exposed to the internet in the way it was.
Finally, if TeenSafe was using Celery for task management, they should have ensured that appropriate security measures were in place, such as using TLS and strong credentials.