Proof of work
Cada verificación le pide al navegador del visitante que resuelva un pequeño puzzle computacional antes de que Caputchin emita un token. Ese puzzle es el proof of work.
Cómo funciona
Caputchin le entrega al navegador un reto y le pide que encuentre un número (un nonce) que, al hacerse hash junto con el reto, produzca un hash que empiece con una cantidad requerida de ceros a la izquierda. No hay atajo: el navegador tiene que probar nonce tras nonce hasta que uno funcione por casualidad. Encontrar un nonce válido lleva muchos intentos; comprobar uno es un solo hash. Así que el trabajo es difícil de hacer pero barato de verificar, y Caputchin confirma que la respuesta supera la dificultad requerida.
Content-Security-Policy
El solver corre en un Web Worker, que el widget crea desde una URL blob:, así que la Content-Security-Policy de la página que incrusta debe permitir blob: para los workers (worker-src blob:, o child-src / default-src como la cadena de fallback). Esta parte es obligatoria: no hay fallback en el hilo principal, así que una política que bloquea el worker bloquea la verificación. Por separado, el solver corre una rutina de WebAssembly por velocidad, y eso lleva dos permisos en vez de uno: hace fetch del módulo desde junto al script del widget, así que ese origen tiene que estar en connect-src, y compila el módulo, lo que necesita 'wasm-unsafe-eval' en script-src. Esa parte es opcional: si falta cualquiera de los dos, el mismo solver corre más lento en JavaScript puro dentro del Worker. Y además es silencioso, porque recaer no es un error, así que si los solves se sienten lentos bajo una política estricta, revisa los dos. Mira sandboxing de juego para la política completa de la página anfitriona.
Por qué disuade el abuso
El punto no es hacer imposible cualquier resolución individual. Es hacer el abuso a escala antieconómico.
Un visitante real resuelve un puzzle en una fracción de segundo y nunca lo nota. Un bot que quiere disparar miles de peticiones paga ese coste de cómputo miles de veces. Si superar el reto cuesta más de lo que vale el spam, el ataque deja de tener sentido financiero. El proof of work cambia el objetivo de "irrompible" a "no vale la pena".
Las perillas
Dos ajustes en la página de Seguridad de una clave afinan el coste:
- Dificultad fija cuántos ceros a la izquierda debe tener el hash, lo que eleva el coste de cada resolución.
- Retos por solicitud multiplica ese coste pidiendo varias resoluciones a la vez.
Un límite honesto
Ningún reto es irrompible; con suficiente dinero, cualquier cosa se puede resolver. El proof of work acepta eso y compite en coste en su lugar. También solo prueba que se gastó esfuerzo, no que un navegador real lo gastó, que es por qué Caputchin lo empareja con instrumentación para comprobar el entorno también.