CAPTCHA reliability improvements in CMS

Clients reported form submission issues caused by inaccurate reCAPTCHA v3 scoring, including legitimate users being blocked and spam still getting through. This fullstack project focused on improving CAPTCHA reliability by changing when and how CAPTCHA validation was evaluated. Updates included moving reCAPTCHA evaluation to form submission and adding support for hCaptcha as an alternative provider.

CMS Architecture

The CMS is a server-side rendered PHP application using an MVC pattern.

• Features are built as modular “cells,” each with its own controller, view, and frontend assets.
• Forms are rendered on the server, with JavaScript added only where needed to enhance interactivity.
• Configuration and third-party integrations like CAPTCHA are managed through a centralized registry.

Languages and Technologies

• JavaScript
• PHP
• HTML

Development Process

• Reviewed client reports and reproduced form submission issues on a staging environment.
• Researched Google reCAPTCHA documentation to better understand token behavior, scoring, and recommended implementation patterns.
• Updated form modules so reCAPTCHA v3 evaluation occurred on form submission instead of page load.
• Improved action naming to give reCAPTCHA more specific context per form.
• Implemented optional support for hCaptcha.
• Tested changes on staging and deployed updates to the shared CMS codebase.

Challenges and Solutions

Challenge:Legitimate users were failing CAPTCHA due to low scores or expired tokens.
Solution: Identified that tokens were generated on page load and expired before submission; moved evaluation to the submit event.

Challenge: reCAPTCHA scoring lacked accuracy across different forms.
Solution: Replaced a generic action name with form-specific actions to give reCAPTCHA more granular data.

Challenge: Working in an unfamiliar part of the CMS codebase.
Solution: Traced the full request flow across controllers, views, and JavaScript to understand where CAPTCHA logic belonged.