Why and for what reason do we need this ?
Magento 2 implements lots of REST APIs that are available on the latest release of Magento 2. Read more on: https://devdocs.magento.com/guides/v2.4/rest/bk-rest.html
REST: to understand what REST means read further on https://www.codecademy.com/articles/what-is-rest
Simply put, REST is a way to allow clients to make requests to your server without knowing anything about each other. Since there are no knowledge stored, there is also no TRUST built in to your requests and responses out of the box and this leaves some doors open to abuse your site services.
Situation created is widely known to all REST based services (not just Magento 2 specific). REST based services need extra protection, authentication, rate limiting etc. to avoid abuse. Services accessed over REST could leak data that could be used as input on non related processes.
Like Credit Card Validation or carding attacks, where a bad actor just uses your site to validate stolen credit card data against payment gateway validation services. Your site offers a configured link to a payment gateway that has the means to validate if credit card is valid. Gaining that knowledge those validated cards are then used for stealing from others and making fraudulent credit card transactions.
Read more on that specific topic (carding) from https://github.com/magento/magento2/issues/28614
How can we avoid this ?
OneStepCheckout added few controls to the mix to help you easily avoid the first wave of such attacks by enabling "Additional validation options for REST endpoints" from Stores > Configuration > Sales > OneStepCheckout and there you can select from a list of checkout related REST endpoints to apply extra validation against request data:
Validate if the request is XMLHttpRequest (is an AJAX request)
If your site does not have any external integrations that would otherwise use REST services its safe to select all endpoints on this selection. This will make sure that all selected endpoints are verified against to be XMLHttpRequest (AJAX requests) and this is often enough to ban all external requests that are not done via special tools that allow attacker to adjust XMLHttpRequest related headers.
If your site has external integrations on REST endpoints choose only requests that are being abused and are not used by your external services.
Note: this is a simple validation rule, if attacker is technical enough they can abuse this validation.
Validate if request needs reCAPTCHA validation (Google invisible reCAPTCHA v3 is used)
From this section choose only abused endpoints and endpoints that are accessible trough checkout. If abused endpoints are not there by default (e.g. a 3rd party payment method adds a new endpoint) you can add those to the list. It is really important that you analyze the attack at this point and enable only specific endpoints you expect to be accessed trough checkout.
The reason you need to add only endpoints accessible trough the checkout is simple, reCAPTCHA is requested only for requests made trough checkout UI. All other requests that have not validated reCAPTCHA will fail, does not matter if made trough AJAX or directly.
Note: this is a hard rule, any request that does not match that rule will fail!
How to configure the reCAPTCHA ?
OneStepCheckout depends on default configuration values for reCAPTCHA, only Google's invisible reCAPTCHA v3 is supported. You can configure reCAPTCHA this way:
- Adding credentials is enough if no other features of reCaptcha is needed from core.
- For M2.3.*:
- for M2.4.*:
For getting reCAPTCHA credentials:
See details about reCAPTCHA https://developers.google.com/recaptcha/docs/v3