Introduction to Amazon Cognito Security - Part 1
Application Security
Charlie Moorton
13 October 2025
In Brief
Common Amazon Cognito misconfiguration exposes risk.
Default self-registration can allow threat actors to create accounts and gain unauthorised access to sensitive internal applications.
Attack path is simple and often overlooked.
By extracting Cognito user pool IDs and client IDs from application code, threat actors can bypass front-end restrictions and authenticate via AWS APIs.
Review user pool security settings.
Security teams should audit Cognito user pools and disable self-registration for internal applications unless explicitly required.
Introducing the Problem
In modern application development, identity and access management (IAM) is a critical component used to manage authentication, facilitate access, and govern roles and permissions.
​
For many organisations offloading IAM to a third-party solution is the most efficient choice. This can offer significant benefits, including enhanced scalability, resilience, and security, allowing developers to focus on core business functions rather than the complexities of identity management.
​
There is a tendency to treat identity providers as inherently secure, but this is rarely the case when factoring in the vast range of different contexts and requirements catered for. A small eCommerce platform expecting users to register for the application possess significantly different requirements to an internal financial dashboarding application. Often organisations are exposed to critical vulnerabilities caused by default settings or deployment approaches that do not consider their application’s threat model.
In this series of blogs, we explore vulnerabilities in deployments of widely used identity providers, specifically focusing on instances where simple misconfigurations or default settings could lead to high impact compromises. Wilbourne’s research in this area focuses on articulating these issues but also identifying the prevalence and ease of exploitation in each case.
This post discusses a common misconfiguration in Amazon Cognito, which provided an avenue for unauthorised access to sensitive internal applications across a wide spread of organisations and industries during Wilbourne engagements. Further posts on this topic will review the application landscape to identify how prevalent this issue is through novel techniques for fingerprinting Cognito applications and probing for the vulnerability.
What is Amazon Cognito?
Amazon Cognito is an identity and access management (IAM) service provided by AWS. It simplifies user registration and authentication for web and mobile applications allowing for streamlined login flows with mature front-end components through AWS Amplify. Gaining popularity in the early 2020s, Amazon Cognito became a cost-effective and feature-rich alternative to other IAM providers like Auth0 and Okta, particularly for AWS native applications.
Key Features and Benefits of Amazon Cognito
1
Ease of Deployment
Amazon Cognito can be quickly deployed as the primary identity provider for an application with minimal infrastructure and development overhead. The supporting development libraries and SDKs such as Amplify are well documented and robust at this stage of their lifecycle.
2
Affordability
Compared to popular market alternatives, Amazon Cognito offers a relatively competitive pricing model based on active users. As a result, Wilbourne has identified a higher prevalence of Amazon Cognito usage amongst small-to-mid sized enterprises, particularly in spaces such as medical technology.
3
Integration with AWS Services
Most of Wilbourne’s clients who have leveraged Cognito have chosen to do so due to their decision to develop a cloud native application in AWS. The use of Cognito allowed for easy integration with other AWS services and a shift towards serverless design and build.
Key Technical Concepts
An understanding of the key concepts described below is required to understand how Amazon Cognito functions. We can then explore how the service can be misconfigured.
1
User Pools
A user pool is a repository of users authorised to authenticate and access an application. Configuration settings define authentication requirements such as multi-factor authentication (MFA) and username formats. Each user pool is associated with a unique identifier that resembles “eu-west-2_xv4c34hcl”
2
Client ID
The client ID is a unique identifier for an application that interacts with a user pool. This identifier plays a central role in the authentication process when submitting credentials. The client ID is a unique string such as “7t40fd9s61cnv152tc8lashi2h”.
Amazon Cognito APIs
AWS exposes a set of APIs for Cognito, allowing applications to interact with user authentication services. These APIs rely on the user pool and client ID to handle registration, login, and user data retrieval.
​
​Importantly these APIs are directly exposed both to client applications and users. This makes sense from the perspective of an OAuth2.0 flow, similar to how login.microsoftonline.com is exposed to users to facilitate login. However, the Cognito APIs are commonly called via front-end JavaScript and are in most cases not visible in a typical browser flow, leading to them being relatively unnoticed.
Example of Interacting with Cognito APIs
An example of how these APIs can be used is seen in the screenshots below, with a user able to register and sign-in to retrieve an access token, before requesting their user details without interacting with any front-end web application through the use of the AWS cli tool:
Step 1: Register to Cognito.
aws cognito-idp sign-up -client-id 7pqvifuqlakr982qbtesaboeh -region eu-west-2 -username charlie.moorton@wilbourne. co. uk -password Aaaaaaaaaaaa1! -user-attributes "Name=gender, Value=male"
Figure 1 - Registering with an Amazon Cognito user pool
Step 2: Use the access token to interact with Cognito.
aws cognito-idp initiate-auth -auth-flow USER_PASSWORD_AUTH -- client-id 7pqvifuqlakr982qbtesaboeh -region eu-west-2 -- auth-parameters "USERNAME=charlie.moorton@wilbourne.co.uk,PASSWORD=Aaaaaaaaaaaa1\!"
Figure 2 - Authenticating with the AWS API
aws cognito-idp get-user -region eu-west-2 -access-token <INSERT ACCESS TOKEN>
Figure 3 - Requesting user details through the AWS cli tool
The screenshot below shows the error message received when self-registration is disabled within the user pool:
aws cognito-idp sign-up -client-id 7t40fd9s61cnv152tc8lashi2h -region eu-west-2 -username charlie.moorton@wilbourne.co.uk -password Aaaaaaaaaaaa1! -user-attributes "Name=gender, Value=male"
Figure 4 - Error received when self-registration is not enabled for a user pool
How can Amazon Cognito be Misconfigured?
By default, Amazon Cognito allows self-registration to a user pool unless explicitly disabled by the application owner. If an organisation creates and connects a sensitive internal application to a newly created user pool without disabling this setting, attackers can simply register an account and gain unauthorised access to internal resources.
This misconfiguration can be seen in the screenshot below:
Figure 5 - AWS console for the Amazon Cognito service showing
that self-registration is set to "Enabled"
This can go unnoticed by engineering teams due to the obfuscation of the APIs from the front-end. A developer creating an application may only include front-end components for login, without realising a user could bypass it completely and register via the APIs.
How the Attack Works
We have created a mock scenario that replicates how this misconfiguration commonly manifests.
1
A mock administrative dashboard is connected to a Cognito user pool for authentication. No registration functionality is exposed on the frontend as it is assumed that only internal administrators will have credentials.
Figure 6 - A mock single-page application using Amazon Cognito
2
By inspecting the application’s JavaScript, both the client ID and user pool ID can be identified.
Figure 7 - Cognito identifiers exposed in application JavaScript
3
As shown previously, a user account can be created and the resulting access token can be retrieved through the AWS cli tool.
Figure 8 - Registering with the application and retrieving an access token
4
The ID token can then be used to authorise the threat actor to the application, and request sensitive functions through the API.
Figure 9 - Accessing the application API
Resolution
The most straightforward mitigation is to audit the self-registration setting for all Amazon Cognito user pools, and ensure it is only enabled by default for public applications.
For internal applications, unless strictly required to allow for sign-up by your organisation’s users, the setting should be disabled. Amazon publish a number of other possible solutions should sign-up be necessary for internal users, including assigning a client secret to the user pool:
https://docs.aws.amazon.com/cognito/latest/developerguide/signing-up-users-in-your-app.html
Impact
The impact of this misconfiguration varies significantly based on the context of the internal application. Some applications will apply role-based access controls separately to Cognito, preventing a threat actor from accessing resources despite being able to authenticate. Other applications will allow threat actors to sign-up arbitrarily access sensitive resources without further restrictions.
​
While this misconfiguration has been known to the security community for a long time, little analysis has been performed on how prevalent the issue is. It is realistic from our experience to assume that a significant quantity of sensitive admin pages are exposed on the Internet that could be trivially accessed, putting organisational data at risk without requiring a complex attack chain
Looking Ahead
The next blog in this series will focus on how fingerprinting of applications vulnerable to this misconfiguration can be carried out and automated. We will present our results illustrating that this issue is an ongoing and serious concern across several industries and sizes of organisation.
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.