Skip to main content

Integrating Google reCAPTCHA v2 with an ASP.NET Core Razor Pages form

CAPTCHA (completely automated public Turing test to tell computers and humans apart) reduces the likelihood of automated bots successfully submitting forms on your web site. Google's reCAPTCHA implementation is familiar to users (as these things go), and is a free service. Integrating it within an ASP.NET Core Razor Pages form is straightforward.


Obtain Google API key

The first thing we need to do is to sign up for an API key pair. The latest documentation for this process can be found on the reCAPTCHA Developer's Guide. Google will provide us with a site key and a secret key. I am storing these keys in the Visual Studio Secret Manager so they are not accidentally checked in with version control. To access the Secret Manager, right-click on the project and select "Manage User Secrets...":

Manage User Secrets

No, these are not my real keys...

As part of the sign up process for the reCAPTCHA keys, we specify the domains for which the keys are valid. Be sure to add "localhost" if you are using the keys for your local development environment.

Client-side integration

We next add a reference to the reCAPTCHA API script in our page. My layout template has an optional "Scripts" section just before the closing body tag, so I am putting the script there. I am reading the public site key from the application configuration (in our secrets.json):

And that's really it as far as the client-side integration is concerned. When the page is loaded, the API script takes care of handling the user response. Once the CAPTCHA has been successfully verified on the client, a g-recaptcha-response parameter will be POST-ed along with our form.

Server-side integration

On the server, we need to verify that a valid CAPTCHA response was provided. To do this, we take the g-recaptcha-response parameter that should have been sent with the form, and verify it using Google's API at Here is a simplified implementation:

There are obviously a lot of ways to customize the behavior on failure. The implementation above returns a generic response to the user--this is really something that a legitimate user should never see. In the unusual case that Google's API is down, we allow the request to proceed, logging the error.

Assuming everything checks out with the CAPTCHA (and any other validation we have on our form), we allow the registration to proceed.

Popular posts from this blog

Mitigating the risk of brute force login compromise using Redis cache in ASP.NET Core Identity

Any application that requires user authentication must take adequate steps to protect the user accounts for which it is responsible. This includes correctly handling workflows such as proper password hashing and storage, providing feedback that doesn't disclose information useful to an attacker, providing means for password reset, etc. The ASP.NET Core Identity membership system provides much of this functionality out-of-the-box, using tried and tested implementations that avoid common mistakes and pitfalls. It is an excellent platform on which to build when developing your application's authentication system. ASP.NET Core Identity provides a means of mitigating brute force login attempts through user lockout. After a configurable number of failed login attempts, a user's account is locked for a period of time. Both the maximum number of attempts, and the lockout period, are configurable. While this is certainly a valid strategy, it does have some weaknesses: The syst

Detecting the user's time zone at registration

This article walks through the process of capturing and detecting a user's time zone at the point of registration. This information can then be used to display time-related information in the local zone of the user. Note that, in most cases, you should still store datetime information in UTC; the time zone is only used for local display. This setup assumes a site running Razor Pages in ASP.NET Core 2.2, although there's nothing particularly framework-specific in what follows. The same ideas should carry over quite easily to, for example, a regular ASP.NET MVC site. We start with a basic registration page: Register.cshtml @page @model RegisterModel <h1> Create an account </h1> <form method= "post" > <div asp-validation-summary= "ModelOnly" ></div> <div class= "form-group" > <label asp-for= "FirstName" ></label> <input asp-for= "FirstName"