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?

asked 2 years ago2247 views
2 Answers

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.

profile pictureAWS
answered 2 years 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 2 years 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