We leverage a lot of Apex remote calls in our Salesforce experience site. We have a public signup page where we allow registration to our site. This is an apex remote method which creates a record in a custom object. Someone enters their info (name, email, etc) and clicks "Submit". The "Submit" button is hidden behind Google reCAPTCHA. This registration page is exposed to public guest user.

Problem is Apex remote calls can be exploited. Someone can perform a signup, record the apex remote call in Chrome network console, and re-submit the call over and over again without needing the UI "Submit" button. This will allow them to spam our registration functionality without needing to go through reCAPTCHA.

Is there a way I can lock an apex remote method called from a guest user behind reCAPTCHA? problem is without an authenticated user, i cant update any flag on the user to say they have completed reCAPTCHA. I can't pass a parameter to the Apex remote either, because that would be exploited via the spamming.

Anyone have any ideas? Thanks!

1 Answer 1


Is there a way I can lock an apex remote method called from a guest user behind reCAPTCHA?

AFAIK, there is no standard way or OOB feature to restrict apex call from a guest user for your use case. I guess Salesforce would monitor these kind of excessive # of spam calls and flag them because it would lead of exploitation of resources in the org, but that can neither revert the problem caused by spammer nor stop the exploit from a different IP address/ device. If you have customized the self registration apex controller or replaced with your own controller, you could have the code in place to prevent duplicate user registration. But that also doesn't stop spammer from replaying apex calls.

One approach that I feel would serve your use case better is to make use of OTP validation before/ during 'Submit' button click. Assumption here is that your registration page captures email address/ mobile # and that you have your own custom registration apex controller. Note that this approach also cannot be considered fool proof and might require additional cost (for OTP delivery service etc.), but IMHO it's slightly better than the usage of reCAPTCHA (it makes it harder for the spammer to replay apex calls easily or at shorter intervals).

  1. Build your own apex implementation to generate OTP (this is fairly easy) and store it in a custom object (required at the time of OTP validation). Your registration page should have a 'Send OTP' button whose sole purpose is to call this apex method (only input parameters are email address or mobile #). This apex method should generate OTP and send it to the user mobile # or email address, so the client browser/ tool is unaware of the OTP generated. You could utilize some external web service for OTP delivery to mobile or email address, as needed.
  2. User enters the OTP in input text box and clicks submit, which would invoke the registration apex method (OTP is sent along with the input parameter). The apex method should have logic to validate the correct OTP before accepting the user registration. Mark the OTP as used after successful registration or one time use of the OTP, so it cannot be re-used for validation or by apex call again.
  3. Note that one caveat with this approach is OTP flooding (spammer could replay apex method for OTP generation), so you will need to have appropriate logic implemented in your apex method to prevent this. For example, no more than 3 OTP requests within 15 min for the same email address or mobile number, Disable 'Send OTP' button for 5 min after it has been clicked etc.
  • Thanks, so no real way to protect publicly called Apex. I'd need some sort of OTP approach or a limit on how many times this method can be invoked. Thanks for your insight. I will allow this question to remain open a few more days and then mark as answered Commented Jun 10, 2022 at 16:22
  • @RyanWerner Sure, I would love to hear insights from others on this . I'm sure SF does some kind of monitoring of such replay attacks, but I don't think they are publicly documented yet. For logged in user sessions, SF does monitor browser fingerprinting and flags session hijack events, but for registration pages exposed to guest users I'm not sure what is in place within SF.
    – arut
    Commented Jun 10, 2022 at 17:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .