This makes me wonder what kind of practice change would be best to help avoid this sort of thing. Maybe anytime you put in something that you know is hacky and insecure as a one-off, you should put a note in wherever you would look regularly, and maybe some kind of reminder too, to make sure that your one-off is either removed or properly secured reasonably quickly.
Or maybe just a rant on PHP and/or frameworks that make it easy to do the wrong thing, and hard or time-consuming to do the right thing.
Looks like a good opportunity for an open source tool that scans a git repository for interesting/private information. Obviously it could be used for nefarious purposes, but it would be helpful for anyone looking to open source an existing repo.
Another alternative is to store credentials in environment variables :)
Probably a good practice. For my current project, I've been careful to never commit any API credentials or other secrets to the repo, even though I don't currently have any intention of making it public. It's harder to know what you're missing, though.
Did something similar, just built a module for our CI tool that checks against sensitive information (secret, salts, hashs, hidden feature), pretty efficient as every dev (myself included) can get lazy and use keys directly in scripts, instead of our Config loader that safely retrieves all that.
Not bad in itself, sometimes all you need is a dirty script, but as other have said, they tend to stick around, a key part of our CI module is actually putting expire date on scripts, or check dates. I will receive an email telling me to check and a warning on the CI at build time. It's been great to keep our code clean while allowing us to still do things dirty when required.
Or maybe just a rant on PHP and/or frameworks that make it easy to do the wrong thing, and hard or time-consuming to do the right thing.