Looks like you committed a .env file previously with some semi-private details contained within it, plus you’ve hardcoded some Cloudinary API credentials. You may want to rotate them before they’re abused by someone.
Edit: oh and some database credentials & getstream.io api credentials
made a little tool to catch these things https://github.com/zricethezav/gitleaks. working on a CI version of it right now as well. gotta protect those credentials.
edit: ci version here - https://github.com/zricethezav/gitleaks-ci. work in progress, trying to add readme and instructions tonight. Also if anyone is interested in making gitleaks-ci into a paid github app... hmu
This is very cool! I built something very similar about a year back [0] -- yours looks like it supports some things that mine doesn't but that I've been wanting to add, such as providing the commit hash of the offending commit, which isn't something mine does due to the git diff parsing package I'm using.
It's too late now in any case. Removing them is cute, but in terms of security credentials can only be rotated now. Removing them doesn't help when someone has already pulled that history previously.
Do you have no process ready to rotate a user's exposed credentials? It's what I would expect from any service provider once they become aware of an exposure.
Isn't this exactly what he explained? The user has a easy toggle on their dashboard to rotate credentials - and if he needs a hand with it, contact their support for some help.
I think the parents question was why they wait for the customer to do something instead of blocking/rotating the compromised credentials once they became aware of their existence.
E.g. I remember reading that Amazon even scans Github for AWS credentials proactively now, since this happened all the time.
True. It should be in the TOS that exposed api keys are subject to being revoked to prevent abuse. At least for certain services, and certain types of tokens.
Edit: oh and some database credentials & getstream.io api credentials