Great write up. Reminder that if you commit these to a Github Gist and the provider partners with GitHub for secrets scanning, they’ll rapidly be invalidated.
Man, talk about unnecessary graphs... ok graph 2 is maybe tolerable, although it's showing the popularity of the projects, not a metric of how many errors/vulnerabilities found in those projects.
I'm not a newspaper editor, but I think if this was an article for one, they'd also say the graphs are unnecessary. It smells of "I need some visual stuff to make this text interesting"...
the wildest part is algolia just not responding. you email them saying "hey 39 of your customers have admin keys in their frontend" and they ghost you? thats way worse than the keys themselves imo. like the whole point of docsearch is they manage the crawling FOR you, but then the "run your own crawler" docs basically hand you a footgun with zero guardrails. they could just... not issue admin-scoped keys through that flow
Algolia really needs to make using the admin key less easy. I’ve almost copied it before when setting up a frontend. It should be tucked away and require auth to view.
Thanks for this. I was maybe using one of these keys until this morning. When I logged in at dashboard.algolia.com and went to Settings -> API Keys, I found that none of the keys (Search, Analytics, Usage, Monitoring) matched the key I was using on a frontend. I made a decent attempt looking for that old key anywhere in their admin panels and could not find it. poof!
So perhaps at some point, they were only giving admin keys (because I don't remember there being a choice; and I would think given the choice I'd make the right one) and when called out (or sometime prior) realized the problem and made a new Settings -> API Keys page. Currently on the page the first one listed is the Search Key, with the subtext "This is the public API key which can be safely used in your frontend code. This key is usable for search queries and it's also able to list the indices you've got access to."
Hey, I'm Natan, Engineering Manager at Algolia. I wanted to acknowledge the issue raised in this thread and for posterity, show how we’re responding.
Some DocSearch implementations exposed write/admin API keys in public frontend config. That should not happen, but sometimes it does, and it underscores the importance of making API key roles and safe usage clearer. Only search-only keys belong client-side. Exposed privileged keys can allow unauthorized index changes or deletion.
We've contacted affected users directly to rotate exposed keys, move privileged keys to backend-only environments, and verify that public configs use search-only keys only.
More broadly, this is a reminder that education and guardrails around API key usage matter, and we're taking that seriously. We’ll continue to ensure this advice is surfaced more prominently throughout our product, and also look to enforce better guardrails to hopefully mitigate it before it happens.
20 comments
[ 3.3 ms ] story [ 37.7 ms ] threadI'm not a newspaper editor, but I think if this was an article for one, they'd also say the graphs are unnecessary. It smells of "I need some visual stuff to make this text interesting"...
So perhaps at some point, they were only giving admin keys (because I don't remember there being a choice; and I would think given the choice I'd make the right one) and when called out (or sometime prior) realized the problem and made a new Settings -> API Keys page. Currently on the page the first one listed is the Search Key, with the subtext "This is the public API key which can be safely used in your frontend code. This key is usable for search queries and it's also able to list the indices you've got access to."
Some DocSearch implementations exposed write/admin API keys in public frontend config. That should not happen, but sometimes it does, and it underscores the importance of making API key roles and safe usage clearer. Only search-only keys belong client-side. Exposed privileged keys can allow unauthorized index changes or deletion.
We've contacted affected users directly to rotate exposed keys, move privileged keys to backend-only environments, and verify that public configs use search-only keys only.
More broadly, this is a reminder that education and guardrails around API key usage matter, and we're taking that seriously. We’ll continue to ensure this advice is surfaced more prominently throughout our product, and also look to enforce better guardrails to hopefully mitigate it before it happens.
Cheers, Natan