By using AWS re:Post, you agree to the Terms of Use
/Cognito Disable update of attribute Phone Number from AWSCognitoIdentityProviderService.updateUserAttributes/

Cognito Disable update of attribute Phone Number from AWSCognitoIdentityProviderService.updateUserAttributes


We have app where user can sign up using phone number which is implemented with Amplify SDK and AWS Cognito. Once user as signed up, we are not allowing user to update their phone number by themselves

For Sign Up Flow we are using Amplify(Auth.signUp and Auth.confirmSignUp)

In one of the pen test findings, security team has informed that users are able to update phone number from Cognito API(> AWSCognitoIdentityProviderService.UpdateUserAttributes) if they have access token .

We have tried 1)By removing phone number as writable attribute from the app client setting in Cognito. but when we did it, User Sign up was failing.

2)By Custom message Lambda trigger on UpdateUserAttributes and send Error response if updating on phone_number, but even there is error response from lambda phone_number is updated and only message is not sent.

Is there any way to block/disable updating the phone number attribute from user/API once the sign up as completed?

3 Answers

The way you want to approach this is from an IAM role/Policy perspective. When users authenticate with Cognito, you can assign a role to that user (either via the console or API). As part of that you can define actions/resources/effects to limit or allow actions with the API calls for Cognito. Specifically, look at the documentation here:

One of the actions is UpdateUserAttributes. After the account has been created in Cognito (through self sign up) the the Lambda can assign the role with this policy. You can further refine the policy by using Conditions to filter on the attributes that are available for update by the user.

The policy would look similar to:

  "Version": "2012-10-17",
  "Statement": [
      "Sid": "Deny updates",
      "Action": [
      "Effect": "Deny",
      "Resource": "arn:aws:cognito-idp:${Region}:${Account}:${ResourceType}/${ResourcePath}"
answered 2 months ago
  • I have tried this and I don't actually see this blocking the Access Token from updating the permissions? As you use the ID token to create an Identity in an Identity Pool and then get temporary creds for the given role you specify. And then with those credentials, the associated role can block updates to user attributes. But before that when you have your access token, you can already update user attributes? So this does not stop this?


Solution 1: Use authorization code sign-in and store the access token in such a way that the user can't access it. The hosted UI offers no native capacity for updating user attributes, so you have to code for attribute updates for the user to have access. This isn't foolproof of course: with a client-side app there's no way you can 100% insulate the access token from the user.

Solution 2: Set up two app clients, one that can write the phone_number attribute and one that can't. Users are global to a user pool, so you can sign users up at #1 and sign them in at #2.

Solution 3: Set phone_number as an alias but not required. Capture the phone number to an immutable custom attribute on sign-up (you can write immutable custom attributes once on sign-up). Use a pre sign-up Lambda trigger to write the custom attribute value to the phone_number attribute.

answered 2 months ago
  • I don't think this is really an answer in my opinion, at the end of the day this is creating a proxy with increase functionality between Cognito and your application. But if you could figure out the details of the user pool you could get the tokens through the hosted UI. Such an approach wouldn't be secure.


I have been having this issue and I think the only way is technically with Developer Attributes, which are not writable by an app client, but only admin-.. calls (not via access token either). If you did want these attributes to be in claims in your token however you will need to write a pre token lambda trigger.

There is one downside to this approach in that if this attribute is mapped from an external identity provider a developer attribute won't work, as it will require an app client to write to it which app client's cannot do. If you aren't doing attribute mapping then this doesn't matter.

answered a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions