I have a story about this, although it's a bit convoluted and not entirely related. But it does showcase low-value usecase compromising a high-value auth mechanism.

I was working on a project, client is a Real Estate agency, they use a CRM where they upload houses and it in turn uploads it to various sites like Zillow. We needed a list of their listed houses, so we wanted to use that data source instead of making a CRUD where they have to add houses yet again.

We ask the CRM sales team about APIs, they tell us that there's no accounts for third parties, client accounts have APIs, so we have to ask the client for an API key (or for their account password).

Which makes sense in general I guess, but the data is public in our case, so the CRM sales staff 's idea was that we should ask the client to let us access their account in order to get public data. We proceeded to scrape the houses from a website like Zillow like cavemen.

As it happens, our project was ancilliary low-value. So I don't doubt that the clients of this CRM are vulnerable in a similar way, and the root cause of the issue isn't evident at all, I can see 2:

1- Paradoxically, having an API that always requires an API KEY (as opposed to allowing unauthenticated access for public data) is less secure, as credentials/tokens will be used more often when not necessary.

2- This CRM effectively acted as an aggregator, consuming the APIs to publish to other vendors, but they don't provide an API for other vendors to read data from them. This effectively causes third party vendors to authenticate as the client, which is just incorrect. Credentials should identify a person/group, not a usecase.