Automating Detection of Misconfigured Cognito Applications - Part 2
Application Security
Charlie Moorton
19 January 2026
In Brief
Simple automation allows the detection of AWS Cognito misconfigurations.
It is possible to create automated tooling that is able to detect misconfigured applications with a high degree of accuracy.
Inconsistency of design does not prevent detection.
Despite applications not all being deployed in a similar manner, it is still feasible to identify those applications allowing authentication via AWS APIs.
Misconfiguration impacts applications already deployed.
A simple test of a relatively small sample size identified live applications impacted by this issue. Affected applications covered a range of differing industry sectors.
Introducing a Detection Oracle
The next step in our research was identifying a method for detecting this vulnerability at scale and measuring the prevalence of exposed applications.
In Part 1, we discussed a common but impactful misconfiguration in Amazon Cognito:
Open self-registration enabled on user pools that access sensitive internal applications.
This allows unauthenticated threat actors to create accounts and gain access via the AWS APIs, often bypassing any intended restrictions enforced by the application's front-end.
In order to do this reliably, we needed to identify a detection oracle, a method that gives us a clear signal when self-registration is enabled on a given Cognito user pool. Crucially, this method needed to eliminate the risk of creating user accounts across the assessed applications, which could trigger incident response processes. Fortunately, Amazon Cognito provides that through its approach to registration error handling.
By attempting to sign up with an intentionally invalid password (for example, aA), the Amazon Cognito API returns different error messages depending on the configuration.
This gives us a clean, non-intrusive way to determine whether a user pool is misconfigured without ever creating an actual user.
Example of Detecting Misconfigured User Pools
An example of a sign-up request intended to identify misconfigured user pools through the AWS cli tool is shown below:
Step 1: Attempt to register with a deliberately weak password.
aws cognito-idp sign-up -client-id 4u7238ek6ulc1gfcsh9gpv8uak -region eu-west-2 -username charlie.moorton@wilbourne.co.uk -password Aa!
Figure 1 - Registering account with non-compliant password
Step 2: Observe the response regarding the password length.
An error occurred (InvalidPasswordException) when calling the SignUp operation: Password did not conform with policy: Password not long enough
Detection Flow
To automate detection using the signup error oracle described in Part 1, two identifiers are required: the UserPoolId and the ClientId. Commonly these values would be embedded within JavaScript as shown below:
JavaScript Identifiers
"aws":{
"region":"eu-west-1",
"identityPoolId":"",
"userPoolId":"eu-west-1_XXXXXXXX",
"clientId":"q5c6ugt8eqdXXXXXXXXX",
"iss":"https://cognito-idp.eu-west-1.amazonaws.com/eu-west-1_XXXXXXXXX"
}
Challenges
Extracting these identifiers reliably across real-world applications presented a number of challenges as explored below:
Real-World Challenges in Extraction of Identifiers
1
Inconsistent Key Names
Cognito configuration key names were rarely standardised across implementations. For example, during testing we encountered a range of variable names for the UserPoolId parameter including COGNITO_ID_USERPOOL, UserPoolId, userPoolWebClientId, and AWS_COGNITO_WEB_CLIENT_ID. This lack of uniformity made direct key matching too inconsistent to be feasible.
2
Diverse Storage Locations
While many applications exposed Cognito values in client-side JavaScript, others embedded them in HTML outside the main application page or fetched them dynamically via endpoints such as /api/config. This required any scanner to support multiple parsing strategies and fallback behaviours.
3
Ambiguous "ClientId" Pattern
The ClientId typically appears as a 25–26 character alphanumeric string. However, similar patterns are common in unrelated parts of application code such as build IDs, analytics tokens, or UUIDs making extraction without additional context prone to false positives.
Given these challenges, we adopted a best endeavours approach to capturing Cognito identifiers. While it may miss edge cases or highly customised implementations, it consistently detected the majority of Cognito-enabled applications we reviewed.
Detection Workflow
The detection workflow proceeds as follows:
1.
Recursively parse the application’s main and login pages for embedded or linked JavaScript files.
2.
Apply regular expressions to extract probable "UserPoolId" and "ClientId" values.
3.
For each combination, attempt a registration request using an intentionally invalid password. The resulting error message is used to determine whether signup is enabled or blocked.
We implemented this workflow within a multi-threaded Go script that output results into a JSON file for analysis.
Assessing a Sample of Applications
With the detection tooling in place, we needed a meaningful set of targets to test it against. To avoid making the sample easy to replicate, the discovery methodology can only be discussed in brief. Essentially, we used standard internet-facing reconnaissance techniques to identify a list of 254 applications that appeared to be using Amazon Cognito or the Amplify SDK for authentication.​
254 Applications Identified
95 Supporting Self-Registration
46 Sensitive Applications
​Once the targets were identified, we ran the scanner across each host to determine whether open signup was enabled. Of the 254 applications, approximately 95 were found to allow for self-registration.
​
While this initial occurrence rate seems high, it is important to note that self-registration being enabled does not constitute a vulnerability unless the protected resource is not intended for public access. Some applications intended to expose registration as a feature. To get a better sense of actual risk we manually reviewed the more interesting hits, prioritising those that showed signs of:
​
-
Admin functionality or internal-facing dashboards.
-
No public signup flow on the site.
-
Staging, test or development environments accidentally exposed.
​
From this follow-up analysis, we identified 46 sensitive applications that appeared to be misconfigured to allow self-registration. There were some high-profile hits within this sample set, covering a range of industries:
Well-known luxury retail brands
Automotive service platforms
Logistics and supply chain tools
Healthtech and clinical applications
Where responsible disclosure programs existed we reported the issues and provided a short proof-of-concept to demonstrate potential misuse. In some of these cases full user registration and API access was possible from no initial access, representing a complete breach of the organisation’s external perimeter.
​
A subset of these applications did not publish any contact details, and frankly looked like test applications or private projects, in which case notification wasn’t possible. This influenced our decision in keeping the sampling methodology private.
Conclusions
This research underscores how a simple misconfiguration in Amazon Cognito can lead to significant exposure, especially for internal tools and admin portals that should be restricted.
​
Despite using a straightforward detection method, we were able to identify a notable number of misconfigured applications, including those belonging to well-known, high-revenue companies. Many of these applications lacked visible signup pages, meaning engineering teams and administrators are likely unaware of the issue and may struggle to detect if unauthorised access is ongoing.
​
There is room to improve the detection process used in this research, particularly to extract Cognito identifiers more consistently with sophisticated parsing or analysis techniques. Our sample also focused mainly on EC2-hosted environments, which could skew results toward smaller or test deployments, and so expanding the scope could reveal more production-level risks.
​
The findings highlight the importance of regularly auditing Identity Provider configurations for applications across your external perimeter, to ensure that default settings are not providing an open door into your environment. Regular penetration testing or secure design review of applications during the development lifecycle would highlight these issues before they became a production issue.
Looking Ahead
The misconfiguration highlighted in this blog post represent a significant risk to any organisation utilising Amazon Cognito as an identity service. We strongly recommend that configuration settings are reviewed in order to ensure a threat actor is not able to gain unintended access to internal applications.
If you would like assistance hardening the deployment of your AWS-hosted application, which may include threat modelling, source-code reviews, penetration testing or cloud security reviews, please do not hesitate to get in touch with us.