Delegated access management

Hosted Login

Multifactor Authentication

Passwordless Authentication

Audit Trail

Identity Brokering

Platform

Service Accounts

Features

Easy integration

B2B (Business to Business)

Self Service

Existing identities

Secure authentication

Use Cases

Learn how to install, setup, and use ZITADEL.

Documentation

ZITADEL Cloud

Self-hosting

Trust center

Examples and Guides

Github Repository

Develop

Get Started

Contribute

Roadmap

Changelog

About Us

Jobs

Contact

Company

Read the blog

Sign up

Login

Pricing

Blog


## Our Journey: Enhanced Security and Transparency

We are committed to transparency, and that is why we want to give a brief update on the recent [security advisories](https://github.com/zitadel/zitadel/security/advisories) that we issued for ZITADEL.

Let’s start with a couple of figures from this year. We started the year with around 2,000 GitHub stars and grew to more than 5,500 in the last 11 months. Our community on [Discord](https://zitadel.com/chat) had around 100 members, and now we have more than that online around the clock, with over 1,300 members in the channel. Container downloads grew to over 400,000 this month.

We’ve been growing as a community and open-source project, as a cloud service, and as an organization. With growth come more eyeballs; with more eyeballs on our software, we get better ideas for solving bugs, improving code quality, and enhancing security. It seems we might have reached a point where [Linus's Law](https://opensource.com/article/21/2/open-source-security) starts to kick in.

While we follow secure coding practices and also conduct regular [penetration tests by third parties](https://zitadel.com/blog/tags/pentest), we actively encourage people and researchers through our [disclosure policy](https://zitadel.com/docs/legal/policies/vulnerability-disclosure-policy) to test ZITADEL and disclose vulnerabilities responsibly. Following our disclosure process, we publish [security advisories](https://github.com/zitadel/zitadel/security/advisories) on GitHub and inform affected users and customers.

Besides application security, we have also enhanced our information security culture and practices over the last year to strengthen our operational security as well. Examples of this include clarifying the [account lockout policy](https://zitadel.com/docs/legal/policies/account-lockout-policy) and successfully mitigating several notable (D)DoS attacks. We have recently updated our [Trust Center](https://trust.zitadel.com/) to provide you with more information about our security practices.

In recent weeks, we mitigated vulnerabilities reported by different security researchers that could impact the security of systems using ZITADEL. Interestingly, some of the reporting parties conducted security research either on behalf of clients or as part of their due diligence process.

After reviewing and closely collaborating with the researchers, we promptly provided patched versions and issued security advisories, prompting affected users to upgrade to these patched versions. Since ZITADEL acts as a critical piece in protecting the confidentiality and integrity of applications, and moreover, could lead to systems becoming unavailable for users, most of the vulnerabilities receive a high severity rating.

Here is a short overview of the findings:
### Password Reset Does Not Respect the "Ignoring Unknown Usernames" Setting (Moderate)

ZITADEL administrators can enable a setting called "Ignoring Unknown Usernames," which helps mitigate attacks that try to guess or enumerate usernames. While this setting was properly functioning during the authentication process, it did not work correctly in the password reset flow. This meant that even if this feature was active, an attacker could use the password reset function to verify if an account exists within ZITADEL.
[Security Advisory Link](https://github.com/zitadel/zitadel/security/advisories/GHSA-v683-rcxx-vpff)

### XSS with User Avatar Image (High)

ZITADEL users can upload their own avatar images. Various image types are allowed, including SVG. SVG files can include scripts, such as JavaScript, which can be executed during rendering. 

Due to a missing security header, an attacker could inject code into an SVG file to gain access to the victim’s account in certain scenarios.
Please check out the details in the [published advisory](https://github.com/zitadel/zitadel/security/advisories/GHSA-954h-jrpm-72pm). You can also read the [researcher’s blog post](https://zxsecurity.co.nz/research/advisories/zitadel-account-takeover/) for more information.

### Race Condition in Lockout Policy Execution (High)

ZITADEL provides administrators the ability to define a Lockout Policy with a maximum number of failed password check attempts. On every failed password check, the count of failed attempts is compared against the configured maximum. Exceeding this limit will lock the user out and prevent further authentication.

In the affected implementation, it was possible for an attacker to initiate multiple parallel password checks, thereby gaining the ability to try out more combinations than allowed by the Lockout Policy.
We have published the following [advisory](https://github.com/zitadel/zitadel/security/advisories/GHSA-7h8m-vrxx-vr4m), and the researchers have provided a [write-up on their blog](https://zxsecurity.co.nz/research/advisories/race-condition-zitadel/).

### Account Takeover via Malicious Host Header Injection (High)

ZITADEL uses the notification triggering request's Forwarded or X-Forwarded-Host header to build the button link sent in emails for confirming a password reset with the emailed code. If this header is overwritten and a user clicks the link to a malicious site in the email, the secret code can be retrieved and used to reset the user's password, leading to account takeover.

Accounts with MFA, especially Passwordless (aka Passkeys), cannot be taken over by this attack.

You can find more information in our [advisory](https://github.com/zitadel/zitadel/security/advisories/GHSA-2wmj-46rj-qm2w).

## Commitment to Continuous Security Improvement

We truly appreciate the time and effort that went into reporting and clarifying the vulnerabilities in ZITADEL. This work will not only better protect our customers, but our open-source community will also benefit from a more secure version of our product.

Pentests are one part of our security measures, and we will continue to commission security audits to third parties. Furthermore, we strongly encourage users to set up MFA, especially Passkeys, to protect their accounts in the best way possible. Although not all vulnerabilities can be compensated for by secure authentication, it still significantly reduces the attack surface. In terms of scope, we are planning to conclude a majority of the rework on our APIs, such as introducing a session API and [switching from a service-based to a resource-based API](https://chat.openai.com/blog/resource-api), and subject those changes to a thorough review. However, we will not limit the scope only to new features but will continue to review existing features and our infrastructure.




In the past few weeks, we mitigated multiple vulnerabilities reported by different security researchers that could have impacted the security of systems using ZITADEL.

Thank you for Making ZITADEL More Secure


At ZITADEL we believe that working transparently creates trust in our project and cloud service. With this mantra as one of the cornerstones of ZITADEL we actively and regularly engage with external security testers to test different scopes of our offerings.

As always we tested ZITADEL against the [OWASP Top Ten](https://owasp.org/www-project-top-ten/) risks. Besides that we instructed our testers to assess our cloud provider’s configuration to reduce the risk of problematic settings, since we run the majority of our infrastructure on Google Cloud Checkout our [trust center](/trust) if you are interested in what services and providers we use.

## TL;DR

The overall result was rated good with only one high issue, which was mitigated during the test. Other issues were minor but nonetheless important for us and were fixed within a few days.

## Findings

In the following section I will give you a short summary and comment on the highest ranked issues. [You can download the full report here.](/blog/2022-12-01-pentest-results-h2-2022-01.pdf) Findings with a low criticality will be mitigated, if needed, during our regular security operations.

## 5.1 Privilege Escalation by Actions

> “The Actions feature allows an authorized user with the role “Organization Owner” to add a grant to a new external user for a project within another organization's scope. An attacker can utilize this vulnerability to create/escalate its privileges on another organization’s projects.”

During the test it was brought to our attention that the tester was able to use a ZITADEL Action to elevate access rights inside a ZITADEL Instance. Even though this vulnerability only could be exploited if access was granted to deploy new Actions, we decided to [publish a CVE](https://github.com/zitadel/zitadel/security/advisories/GHSA-c8fj-4pm8-mp2c) and create a mitigation instantly.

Exactly these types of findings are the reason why we think working with external testers is an important part of the integral security of a project.

## 5.2 Missing Logging for Firewall

> “Logging for existing Firewall rules is deactivated. Policy violations will not be logged and thus cannot be monitored.”

We use the Google Cloud Firewall to policy traffic from different networks. Especially traffic flowing from our Google Cloud Run deployment to the VPC Interconnected CockroachDB Dedicated Cluster.

To improve our observability of violations we activated the logging and integrated the information into our monitoring platform.

## 5.3 Insufficient Monitoring

> “No policies were defined in the Google Cloud Platform to be informed about possible changes or security-relevant incidents. An attacker can apply unnoticed changes or perform attacks on the ZITADEL services.”

In the past we mainly used the Google Cloud Monitoring Suite to observe and alert behaviors of our service. After doing this test we revised our standpoint and created an umbrella monitoring platform to ingest all the observability data from many different systems and services we rely on. To specifically address this issue we also incorporated the Google Cloud Audit log.

We will follow-up with an upcoming blog about how we observe and monitor ZITADEL Cloud in more detail.

## 5.4 Basic Roles in Use / 5.5 Service Account with Admin Privileges

> “Basic Google Cloud Platform roles are assigned, this does not follow security best practices as these roles can have extensive permissions.”

> “Custom service accounts have administrative privileges assigned. A compromised service account would have extensive permissions on the assigned services.”

Some users had broad permissions for their needs. After highlighting this during the test we removed overarching permissions and integrated the permissions management into our Terraform process where a four-eye process is required for all changes. 
To keep everything auditable we store our terraform files in a Git repository and we ingest the Google Cloud Audit Events into our monitoring platform.


A security analysis of ZITADEL was conducted with an external specialist. Learn more about the scope and results.

Pentest Results H2 / 2022


During the first half of 2021 an external specialist conducted a security analysis of ZITADEL. We want to show you the results, what we already did and what we’re planning to do in the future.

## TL;DR

The overall result was rated as good with only one high issue, which we already mitigated partially. Other issues were minor but nonetheless important for us and were fixed within a few days. Others still need more thinking from our side to find a solution that not only solves the immediate risk, but also gives the users a real benefit. Until then a lot of the findings can be mitigated from the users themself by using either Passwordless (WebAuthN) or at least by protecting their accounts with a second factor (2FA).

## Findings

In the following section I will give you a short summary and comment on the highest ranked issues. The number indicates the external assessment according to the Common Vulnerability Scoring System (CVSS).
[You can find the full report here.](/blog/2021-11-11-pentest-results-h1-2021-01.pdf)

### 8.1 Data not Encrypted at Rest (CVSS 8.2 / High)

> “The ZITADEL Console web application does not encrypt data at rest. An attacker with access to the database, can access the stored secret and personal identification information data.”

Although ZITADEL does not encrypt its database, the storage (hard disks) is encrypted. Furthermore, ZITADEL either hashes (bcrypt) or encrypts (AES) certain events for example passwords, OTP Secrets, private keys or temporary codes.

### 8.2 Failed Login Attempts Not Displayed (6.5 / Medium)

> “The ZITADEL Console web application does not display failed login attempts after a successful authentication. An attacker may profit of this missing control, since a user will not know, that he was subject to an attack.”

We certainly lack a corresponding display and we’re planning to have such in the near future. For the moment a user is able to see these and all other events that have occurred on his user on the “Personal Information” page in the “Activity” section:

<img src="/blog/2021-11-11-pentest-results-h1-2021-02.png" width="60%" alt="" />

To mitigate the risk of an attacker attempting to log into your account, we highly recommend using Passwordless (WebAuthN) or at least protect your account with a second factor (2FA) for example Universal Second Factor (U2F) or One Time Password (OTP). ZITADEL allows managers to enforce the use of multi factor or passwordless authentication.

### 8.3, 8.4, 8.6 Missing Protections for Username / Password Authentication

I would like to take a look at the three points together, because the focus is on protecting authentication using usernames and passwords. To say it in advance, these can be mitigated considerably by using WebAuthN or at least a 2FA mechanism:

- 8.3 Missing Protection Against Online Guessing (6.5 / Medium):
  > “The ZITADEL Console web application does not protect user accounts with an application layer mitigation mechanism against automated brute-force attacks. An attacker with access to the login page can perform an online brute-force attack to guess a user’s password.”
- 8.4 Consider Restriction of Common or Compromised Passwords (6.5 / Medium):
  > “The ZITADEL Console web application does not offer the option for IAM Administrators to restrict the usage of common and compromised passwords. An attacker can be successful using a wordlist based brute force attack to takeover user accounts.”
- 8.6 Username Enumeration Possible (4.3 / Medium):
  > “The ZITADEL Console web application login allows enumeration of usernames, due to a warning that is showed after entering a non-existing username. An attacker with access to the login page can perform an online brute-force attack to enumerate existing usernames.”

To mitigate against brute-force attacks at least on a network layer, we use an IP-based rate limiting for our cloud service and dedicated instances. While we also provide a possibility to create a lockout policy, we do not recommend using it, as it also enables attackers to Denial-of-Service a user. Therefore a reasonable solution would be to use Captchas and prompt users to solve it when a user fails to enter a correct password multiple times.

When using a weak password an attacker's chance to take over an account is even higher. Giving organisation administrators the possibility to restrict certain passwords or make users aware that the password they use, might be weak or compromised will be an enhancement we plan to implement in the future.

We’ve discussed a lot whether we should show a warning that the entered username does exist or not. But the fact that a user can authenticate using external identity providers (e.g. Google) somewhat made it obsolete, because when the user enters their username, we might have to redirect them to their identity provider, which will disclose the fact that the user exists. Moreover, a malicious user who already has access to ZITADEL might gain access to this information anyway (e.g. through the client application).

### 8.5 IAM Policies Not Enforced (5.3 / Medium)

> “The ZITADEL Console web application fails to disable user registration and password
> authentication on the server-side. An attacker who knows the technical details, on how to
> register a user, can register a user without access to any projects or organization
> information.“

A registration of a user, which would not have been allowed is certainly a problem and we fixed it. However, there are possible measures and facts that mitigate this issue. First of all a successful registration only allows a user to authenticate, which he might already be able to do so in another organisation, but no authorization to any project is granted by default. So if applications do their supposed authorization checks, they will not have a problem. As the user will not get any manager role within ZITADEL, he will as well not gain access to any information of other users of his organization.

### 8.7 Verbose Error Messages (4.3 / Medium)

> “The ZITADEL Console web application shows verbose error messages in the HTTP Header Grpc-Message. This information can be helpful for an attacker to mount further attack steps.”

Due to the fact that ZITADEL is OpenSource, a lot of this information can be obtained anyway. But we definitely see room for improvement here, especially from a usability aspect and we will continuously improve this.

### 8.8 Consider Usage of Refresh Token (3.3 / Low)

During the security analysis, refresh tokens could not be tested because we were still implementing them. We released this feature the following week (see [v1.8.0](https://github.com/zitadel/zitadel/releases/tag/v1.8.0))

### 8.9 Logout Does Not Terminate Session (3.3 / Low)

Although this was only rated as low (3.3), we wanted to solve this issue quickly. We also found a bug where we would terminate the session and delete it from the database table. But when we did a query, we would make sure to apply newer events to the found session (using the event sequence of the found session). At first glance this totally makes sense, because the projection might be a little behind and a new session might not even be in the database, yet. The problem was that exactly this piece of code did not handle the logout event. This was an [easy but important fix](https://github.com/zitadel/zitadel/releases/tag/v1.10.5) we provided a couple of days after the security test. It also demonstrated to us that we need more automated tests on the query side of our APIs.

## What we are planning to do

We have a fast forward strategy and while we’re releasing a lot of new features frequently , we need to keep code and application security in mind. Therefore, we want to challenge our security from the outside more often and plan to do such security audits at least every six months. Moreover we have a [basic responsible disclosure policy](https://github.com/zitadel/zitadel/blob/main/SECURITY.md) that we want to expand further over the near future, most likely coupled with an official bug bounty program.

Furthermore we will have to use the potential we gain through our CQRS / Eventsourcing architecture and generate use case based reports, e.g. present a user not only failed login attempts but also other relevant events that have taken place since the last successful login, such as gaining or losing access to a project and so on.

And last but not least, we are going to push passwordless authentication (WebAuthN) further as this solves a lot of problems regarding compromised or weak passwords.


During the first half of 2021 an external specialist conducted a security analysis of ZITADEL.  We want to show you the results, what we already did and what we’re planning to do in the future.

Pentest Results H1 / 2021

All posts/ #pentest

Thank you for Making ZITADEL More Secure

Pentest Results H2 / 2022

Pentest Results H1 / 2021

Why

Explore

Company