8

From some time I am receiving an error code browser-error during ReCaptcha's verification on a Web App (Node back-end, HTML / JS front-end).

This thread here explains that it's an error which comes from not having a domain added in the whitelist for ReCaptcha Enterprise. However, I am not using ReCaptcha Enterprise. I am only using ReCaptcha v3. And in the documentation there are no mentions of the Error Codes.

I have my domain added properly in the ReCaptcha console.

There is also another thread where the user found out it mostly happens in Safari. However, didn't provide any solution.

I don't think simply ignoring this error in the back-end is the correct solution.

Why do "browser-error" error happen? What would be the correct steps to solve this problem?

Chique
  • 735
  • 3
  • 15

1 Answers1

2

I've found one potential cause: the connection to ReCaptcha in the user's browser fails.

I verified this using the "Network request blocking" feature in Chrome. When the connection is blocked, recaptcha.execute() returns a token, but that token generates BROWSER_ERROR when validated on the back-end. I imagine that a timeout or other network issue would fail in similar fashion.

As for how to handle it… Ideally the frontend would be able to detect this case and simply call execute() again to retry. Unfortunately, it's difficult to distinguish between success and failure on the frontend side. You might think to use an error callback:

grecaptcha.enterprise.execute(siteKey).then(
  token => console.log('OK', token),
  err => console.log('fail', err)
);

… But that doesn't help because both success and failure invoke the same "OK" callback. I did notice that token.length differs: ~1720 bytes for a successful score, vs ~490 bytes for an error. But it's probably unsafe to rely on this property.

So it seems you need to pass the token to your backend service, validate it there, and only then will you know whether the frontend has to retry or not.

(Full disclosure: I'm using ReCaptcha Enterprise)

mamacdon
  • 2,899
  • 2
  • 16
  • 16
  • 1
    Very good explanation and thought process. Even though this is a "manual hack", since anything based on these assumptions might not hold true in a future update, as these are not documented, but still, these are very good assumptions and can be used in a meaningful way. Bonus points for sharing that a network block results in this issue, which can be detected in the front-end easily, and maybe can use that to show some sort of error in the client, or some other work-around. Still looking for the work-around though. – Chique Jun 27 '23 at 20:31