Zapier Storage Exposes Sensitive Customer Data Due to Poor User Choices
Zenity research team has recently discovered a potential customer data leakage in Storage by Zapier, a service used for simple environment and state storage for Zap workflows. With only a few simple steps and no authentication, we were able to access sensitive customer data. Given the nature of this flaw, it would be easy for bad actors to recreate our approach and access the same sensitive data without significant expertise.
Turns out, Volkis has already identified this issue in August 2020, almost 2 years ago. Our research presents a workaround to the mitigation put forth by Zapier after the original discovery.
Zapier security team has been responsive and quick to analyze and act on the issue. Following Zenity’s disclosure, the Zapier team has notified all affected customers. However, data could still be leaked today due to poor customer secret choices.
If you are using the Storage by Zapier or Code by Zapier apps to store data, that data could be available for anonymous access. Scroll down to What should I do now for a concrete checklist to ensure your data is secure.
No, Zapier is a secure platform in and of itself. Unfortunately, no platform is 100% secure and security vulnerabilities are commonplace even with the world’s largest organizations. However, security of the Zapier platform itself is only one part of the story, and it is not the most important. The other, more important aspect is what YOU build on top of Zapier. When you create a Zap, you could create a vulnerability that exposes your organization to risk. This point is true for any No-Code/Low-Code platform, and is not unique to Zapier. No-Code development is still development, and you must own your part of the shared responsibility model. To learn about best practice for secure low-code/no-code development, see OWASP Top 10 for Low-Code/No-Code.
Ensure you are using best practice when building and maintaining your Zaps and involve your security teams for guidance. If you’re looking for an automated governance solution, Zenity can help by continuously scanning your Zapier environment for security issues and allowing you to set guardrails. With dozens of security policies that detect data leakage, insecure secret storage, identity misuse, over-provisioning and more, Zenity enables you to accelerate low-code/no-code development, risk free.
March 16 2022 – Zenity finds the vulnerability and disclose it to Zapier
March 20, 2022 – Zapier initial response
March 24, 2022 – Zapier acknowledge the vulnerability with medium severity, and issued a $400 reward
May 20, 2022 – Zapier resolves the case
June 21, 2022 – Zenity coordinates the write up publication with Zapier
July 1, 2022 – Zenity publishes the writeup after Zapier has notified its relevant customers
According to Zapier the Storage by Zapier connector allows users to:
“Quickly store and retrieve small values of data. Allows you to reference data between Zap runs or share data between different Zaps.”
Under the hood, Storage by Zapier (and other connectors such as Code by Zapier) are based on https://store.zapier.com. Calling the endpoint returns a developer-oriented documentation::
“”what is it?”: [
“store.zapier.com is a simple storage REST API that you”,
“might use to stash a bit of state. we use it to power”,
“`StoreClient` in our Code steps of Zapier – you can read”,
“more docs at https://zapier.com/help/code-python/ or at”,
“https://zapier.com/help/code/.”
],
“—————“: “——————————————-“,
“what can it do?”: [
“only one endpoint – GET & POST to read and write, PATCH to update”,
“store any value that is JSON serializable”,
“BYOS (bring your own secrets) for authentication”
],
This endpoint is being used by the Storage by Zapier and Code by Zapier connectors, Both of them store data on https://store.zapier.com.
Investigating Zapier’s storage, we found the only protection on user data is a secret provided by the client (Bring Your Own Secret), which has to be a UUID4 string. Beyond that, there is no user-level or account-level authentication in place.
Before August 2020, users could pick any secret they wanted, including extremely simple ones like 123456789, secret, or password. To address the vulnerability found by Volkis, Zapier began enforcing the usage of UUID4 secrets. Those secrets are much harder to guess but can still lead to collisions among users in rare cases. This solution is alright, but it still leaves room for data leakage as we’ll show below.
To show how we accessed Zapier user data, let’s take their own example for using https://store.zapier.com.
“how does it work?”: {
“always provide either `?secret=12345` or `X-Secret: 12345`”: “”,
“GET /api/records”: [
“will return a full object of all values stored by default.”,
“you can also specify only the keys you want via the”,
“querystring like`?key=color&key=age`.”
],
First, we issued the following request (through our browser):
https://store.zapier.com/api/records?secret=12345
Notice that according to the official documentation, as our secret is not a valid UUID4, we should receive an error from the server.
To our surprise, we received a JSON object of what appeared to be user IDs and names!
Even though current users supposably can’t use non-UUID4 secrets while using Storage by Zapier we managed to scrape sensitive up-to-date data using legacy secrets.
Among the data we found were:
In order to see what data can be leaked, we decided to enumerate the storage service with public common password lists.
The secrets wordlists we used are:
To bypass any throttling protection or request rate limits imposed by Zapier, we wrote a script that rotates the source IP address every 200 requests. As a result, we did not encounter any hang ups during our script run.
This vulnerability impacts every Zapier customer who uses the Zapier Storage by Zapier connector, or the Custom Code connector with the StoreClient Python or JavaScript class. The issue allows customers to use insecure secrets, thus exposing their data to unauthenticated observers.
The endpoint https://store.zapier.com is used as storage space for key-value pairs generated by Zapier customers within their Zaps.
There are a few inherent security problems with this design:
According to Zapier documentation, data unused for over 3 months gets deleted. This means that any data accessed through this vulnerability is up-to-date. Moreover, this allows attackers to periodically retrieve data from the said secrets to discover if more sensitive information has been written to the secret entry in Zapier’s storage.
Identify all Zaps that use either Storage by Zapier or Code by Zapier apps. For each one, go through their connections and make sure they are using strong secrets. Here is how:
Storage by Zapier:
Code by Zapier:
Introduction Enterprises are racing to adopt AI copilots and low-code/no-code platforms to innovate and maximize...
Microsoft Fabric is an end-to-end analytics and data platform that covers a wide range of functionality, including...
What Happened? Varonis researchers have recently disclosed that several government agencies and private-sector...
We’d love to chat with you about how your team can secure and govern AI Agents everywhere.
Book Demo