Meta-data is overwritten with subsequent signup requests

[naegelin]

Bug report

Describe the bug

Possible security vulnerability

When sending a signUp api call to an already existing user with attached meta-data, the user's existing meta-data is overwritten in an unauthenticated context.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Find a user that exists and has existing meta-data in your supabase project
2. Issue another signUp api request for that same user's email with new meta-data
3. observer the meta-data on the API response

const { user, session, error } = await supabase.auth.signUp({
        email: email,
        password: password,
    },{
        data:{
            phone: phone,
            name: name,
            company: company
        }
    })

Expected behavior

1. If a user is already signed up, the metadata should not be updated
2. Nice to have: If a user is already signed up the API should respond with something like HTTP status code 409 instead of User object.

[naegelin]

Update - if I use the service account to inspect the auth.users table the metadata is not updated there so it seems that its just a bug in how the API endpoint responds upon a secondary signUp call.

[bnjmnt4n]

This is actually a security fix where duplicate signup requests will return a successful response (with a randomized UUID) to prevent leakage of whether user has signed up for a service before. See supabase/auth#1517. I think the auth documentation will need some updating to reflect this, since there have been a much of similar issues raised about this behaviour recently.

[naegelin]

Knowing that a user has already signed up is imho not in and of itself a security risk unless the api allows unlimited amounts of requests to try to 'brute force' out an accounts list. I would argue that knowing that an account already exists is important for most developers when building a useable workflow especially as users over time may have forgotten if they already signed up. Having to track this through a 'profiles' table or similar makes the auth feature less elegant .

[hf]

Fixed in: supabase/auth#825