Unprotected/insecure create customer API

[mischabraam]

Preconditions and environment

• Magento version 2.4.6

Steps to reproduce

1. Create a new customer with unprotected POST REST API. As test body you can use the following.

POST http://www.magento2.test/rest/all/V1/customers

{
    "customer": {
        "group_id": 0,
        "email": "testing@spammers.com",
        "firstname": "Test",
        "lastname": "Spammer",
        "gender": 0,
        "store_id": 1,
        "website_id": 1
    }
}

Expected result

The customer is not created, you should get an error like "auth is missing".

Actual result

The customer is created blindly with some attributes having default values. This makes it possible for spammers to create customers endlessly. See the following screenshots as proof of this insecure behavior.

What confuses me is that the GET and PUT API's seem to be secure. But why not the POST?

Additional information

No response

Release note

No response

Triage and priority

• [ ] Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• [ ] Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• [ ] Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• [ ] Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• [ ] Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant[bot]]

Hi @mischabraam. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:

• @magento give me 2.4-develop instance - upcoming 2.4.x release
• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this

• To learn more about issue processing workflow, refer to the Code Contributions.

  Join Magento Community Engineering Slack and ask your questions in #github channel. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

[m2-assistant[bot]]

Hi @engcom-Bravo. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
• [ ] 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
• [ ] 4. Verify that the issue is reproducible on 2.4-develop branch
  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
• [ ] 5. Add label Issue: Confirmed once verification is complete.
• [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

[engcom-Bravo]

@magento give me 2.4-develop instance

[magento-deployment-service[bot]]

Hi @engcom-Bravo. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @engcom-Bravo, here is your Magento Instance: https://436b8cf6150d63d7a4efa837a3ebefa8.instances-prod.magento-community.engineering Admin access: https://436b8cf6150d63d7a4efa837a3ebefa8.instances-prod.magento-community.engineering/admin_5a9e Login: 4fa3bbdb Password: b2f5ad0b1669

[engcom-Bravo]

Hi @mischabraam,

Thank you for reporting and collaboration.

Verified the issue on Magento 2.4-develop instance and Magento 2.4.6 instance and the issue is reproducible,But it is an expected behaviour of Magento.Kindly refer the screenshots.

Kindly check this doc https://developer.adobe.com/commerce/webapi/rest/use-rest/anonymous-api-security/. As per this doc

The following APIs remain accessible to anonymous users. Most of these must remain accessible to support the checkout and add-to-cart Ajax functionalities.Preventing anonymous access to these endpoints could cause third-party integrations to fail.

Kindly let us know if you are still facing any issue.

Thanks.

[mischabraam]

Preventing anonymous access to these endpoints could cause third-party integrations to fail.

Very true. If you would secure this API by adding a resource in webapi.xml this will be not backwards compatible. However, that should not be a reason to not change it. :)

I think it's weird to force a bearer token (older versions) or oauth token for getting a customer, changing them, changing products, adding products, bot NOT for creating a customer. I can easily create thousands of spam customer accounts, reset their passwords and place fake orders with these fake accounts, fun fun fun for spammers. Don't you agree at least this is weird (despite what the docs state)?

[engcom-Bravo]

Hi @mischabraam,

Thanks for your update.

We are considering this as Feature request as it is an existing behaviour of Magento.

Thanks.

[maghamed]

@magento give me 2.4-develop instance

[magento-deployment-service[bot]]

Hi @maghamed. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @maghamed, here is your Magento Instance: https://436b8cf6150d63d7a4efa837a3ebefa8.instances-prod.magento-community.engineering Admin access: https://436b8cf6150d63d7a4efa837a3ebefa8.instances-prod.magento-community.engineering/admin_cdf6 Login: 8fea0ff4 Password: 258e6f80da2b

[DuckThom]

@mischabraam

I think if you want to protect such routes from spammers you would need to look into using (re)captcha: https://developer.adobe.com/commerce/webapi/rest/use-rest/protected-endpoints/#recaptcha

I think it's weird to force a bearer token (older versions) or oauth token for getting a customer, changing them, changing products, adding products, bot NOT for creating a customer.

Correct me if I'm wrong but if an auth token was enforced on the create customer API, wouldn't that block the registration flow for things like standalone frontends that communicate with Magento using the REST API?

As for the creation and updating of products, there's also a difference between admin/integration tokens and customer tokens. For example, customer tokens cannot do such actions whereas admin/integration tokens have access to basically anything you can do in the admin panel (assuming the permissions for the token are set correctly).

[mischabraam]

Correct me if I'm wrong but if an auth token was enforced on the create customer API, wouldn't that block the registration flow for things like standalone frontends that communicate with Magento using the REST API?

I haven't built a stand alone front-end myself (yet). But theoretically, no. In your stand alone front-end you'll have to make several API calls to Magento. Most of them require a token (bearer or oauth-v1). To create a customer you currently omit the token. This omit would be the only change in your stand alone front-end.

Diving more into this (and reading the docs, thankyou) I've found other API's I can easily exploit to get information. The "isEmailAvailable" is also unprotected and public. I've created a quick patch, see below.

GITHUB-37374_customer_disallow_anonymous_apis.composer.patch

[DuckThom]

I agree that from an integration perspective it makes sense to require some sort of token to those endpoints, yes.

However, I still don't think it would work for standalone frontends if the token is always required.

Let's say a token was required for the createCustomer call. When you submit a registration form directly to the Magento REST API, you'd also need send that token from the browser to Magento. This token could easily be read via the dev tools in the browser and could then be used to automate/spam requests once more (or worse, if it's an admin token, access the admin endpoints).

I think a solution could be to have a toggle or setting in the Magento admin panel which can be used to allow or disallow anonymous API's.

• Allowed: you'd have the current situation which is useful for standalone frontends, or;
• Disallowed: only integrations can effectively access the API's.

When disallowed, a standalone frontend could still be used, though you'd need something like NextJS where you could add the token via an API route: browser > NextJS api route to add token > Magento API. And even then, a bot could abuse the API route to still make the calls to Magento.

[mischabraam]

You would have to built in logic to accomplish that I guess, instead of a change in the webapi.xml. But if you think that's necessary, then yeah ok, sounds good. I would suggest then that the "disallowed" option would be the default? But I'm open for your opinion.

[DuckThom]

The default value kind of depends on if it should be a breaking change or not I suppose.

If the default will be disallowed then it would mean that, without changing the configuration during an upgrade, the currently anonymous API routes will no longer be accessible.

Personally I think making it opt-in (so with allowed as default value) would be better/more upgrade friendly.

[mischabraam]

Correct, just like when the deprecated bearer token by default changed to not-accepted, unless you configure it manually to use it. That's my basis to suggest it here also.