El 14 de agosto de 2026, Firebase amplió App Check para soportar reCAPTCHA Enterprise como proveedor de atestación en móvil —Apple, Android y Flutter— en fase Preview. Respuesta corta: es una buena noticia para frenar el abuso automatizado contra tus APIs, pero al estar en Preview no deberías apoyar en ella flujos críticos todavía. Aquí tienes qué ha cambiado, a quién le importa de verdad y qué haríamos nosotros con un cliente en esta situación.

Qué ha pasado

El 14 de agosto, en sus release notes, Firebase anunció que App Check ahora admite reCAPTCHA Enterprise como attestation provider para apps móviles (Apple, Android y Flutter), en Preview. Hasta ahora App Check se apoyaba en Play Integrity (Android), App Attest / DeviceCheck (Apple) y reCAPTCHA (web). reCAPTCHA Enterprise entra como una opción adicional también en el móvil.

No es un movimiento aislado. Un día antes, el 13 de agosto, Firebase AI Logic sumó el modelo estable gemini-3.7-flash con enforcement automático de App Check para proteger el acceso directo a la API de Gemini desde las apps. La lectura es clara: Google está posicionando App Check como la capa anti-abuso por defecto no solo para tu backend, sino también para las llamadas a IA que salen del cliente.

Recordatorio rápido: qué es App Check y qué NO es

App Check verifica que las peticiones a tu backend vienen de tu app legítima y sin manipular, y no de un script, un emulador o un binario parcheado. Emite un token de atestación de vida corta (TTL configurable entre 30 minutos y 7 días) que tus servicios —Firestore, Storage, Cloud Functions, Realtime Database o tus propios endpoints— validan antes de responder. Las peticiones se clasifican en verificadas, de cliente desactualizado, de origen desconocido o inválidas; con el enforcement activado, solo pasan las verificadas.

Importante, porque aquí se generan la mayoría de malentendidos: App Check no es autenticación de usuario (eso es Firebase Auth) ni autorización. No sustituye a tus reglas de seguridad ni a la validación de permisos en servidor. Es una capa contra el abuso a nivel de app: scraping de tu catálogo, fuerza bruta sobre endpoints, farmeo de tu API y, cada vez más, inflar tu factura de tokens LLM.

Qué implica para tu producto

  • Coste directo. Si expones IA generativa (RAG, generación de contenido) desde el cliente, cada request abusiva cuesta dinero real en tokens. El enforcement automático de App Check en AI Logic pone un muro delante de la API de Gemini. Si tu factura de IA depende del volumen, esto es control de costes, no solo seguridad.
  • Superficie de scraping. Comparadores, retail con catálogos y precios, disponibilidad, datos de mercado… son objetivos habituales de raspado competitivo. App Check eleva mucho el coste de automatizar contra tu app.
  • Dónde encaja reCAPTCHA Enterprise. Aporta una señal de riesgo graduada (no un simple sí/no) y es útil justo donde Play Integrity o App Attest se quedan cortos: dispositivos sin Google Play Services, entornos corporativos gestionados, o escenarios de sideloading —cada vez más relevantes con la DMA y las tiendas de terceros—. Si necesitas puntuar el riesgo en lugar de bloquear en binario, es la pieza que faltaba.
  • El asterisco de Preview. Preview significa sin SLA y con API sujeta a cambios. No es para poner en el camino crítico de flujos que rompan el negocio si fallan.

A quién le afecta (y a quién no)

Sí, con prioridad: FinTech e InsurTech con endpoints de KYC, pagos o cotización; apps con IA generativa expuesta al cliente; comparadores y RetailTech con catálogos y precios apetecibles para el scraping; y cualquier producto con picos de coste por request.

Menos urgente: MVPs sin tráfico real, apps internas de empresa ya protegidas tras MDM/VPN, y backends sin datos sensibles ni coste marginal por petición. Aquí App Check suma, pero no es la primera batalla.

Nuestra recomendación

  • Activa App Check ya, pero en modo monitor. Empieza con los proveedores estables (Play Integrity + App Attest) sin enforcement para medir la proporción de tráfico verificado, de origen desconocido e inválido antes de bloquear nada. Bloquear a ciegas rompe a los clientes con versiones antiguas de tu app y te llena el soporte de tickets.
  • reCAPTCHA Enterprise: pruébalo en staging si tu caso lo pide (sideloading, dispositivos sin GMS, necesidad de señal graduada), pero no lo pongas como único proveedor en el camino crítico mientras esté en Preview. Nosotros no lo usaríamos todavía para gatear un flujo de pago en producción.
  • No lo confundas con seguridad completa. Sigues necesitando reglas server-side, rate limiting y validación de permisos. App Check es defensa en profundidad, no una bala de plata.
  • Cuida el debug provider. Úsalo solo en desarrollo y CI; que un token de debug no acabe nunca en un build de release.
  • Presupuesta la fricción. Un enforcement mal medido dispara el soporte y puede tumbar conversiones. La regla de oro: primero métrica, después bloqueo.

En resumen

reCAPTCHA Enterprise en App Check para Flutter es un buen añadido para quien tiene APIs valiosas o coste por request, especialmente con el auge del sideloading. Pero es Preview: adóptalo en monitorización y staging, no en flujos que no puedas permitirte que fallen.

En Dribba construimos apps Flutter con backend propio (Go sobre Cloud Run) desde 2011 y somos Flutter Partner oficial de Google desde 2017. Si estás valorando cómo blindar tus APIs sin romper la experiencia de tus usuarios, escríbenos. Y si quieres el contexto de fondo, tenemos guías sobre seguridad en MCP y agentes de IA y sobre por qué elegimos Go para backend de alto rendimiento.