Click to Pray API Leak: 700k Users Exposed in 2026

What actually happened to Click to Pray

Click to Pray is the official app of the Pope's Worldwide Prayer Network, available in seven languages across iOS, Android and the web, and as of July 2026 it counted 719,517 registered accounts. According to security researcher BobDaHacker, writing on her blog and reported by The Register, the app's backend API was handing out other people's names, email addresses, country, date of birth and account-deletion status to anyone who asked — no login required.

The researcher says she reported the flaw privately on 3 January 2026. Nobody from the Pope's Worldwide Prayer Network replied. The Register also contacted the organisation for comment ahead of publication and received no response, a detail corroborated by Dark Reading's own coverage of the incident.

The root cause: a textbook IDOR failure

The mechanism is an Insecure Direct Object Reference, or IDOR — one of the most common and easiest-to-exploit web application flaws in existence. New Click to Pray accounts are assigned sequential numeric user IDs. The API endpoint GET https://api.clicktopray.org/user/users/{id} would return full account data for whatever ID was requested, with zero check on whether the requester actually owned that account.

As BobDaHacker put it, "Thou shalt not authorize, apparently." With no rate limiting in place either, scraping every one of the 719,517 accounts required nothing more sophisticated than a loop incrementing an integer — a one-line script, not a nation-state exploit.

A second issue compounded the risk: the sign-up endpoint returned a validation_hash directly in its response, the same UUID used in the email verification link — meaning an attacker could register and verify an account under someone else's email address before the real confirmation message even arrived. The researcher also noted the genuine verification emails failed domain authentication checks, making real Click to Pray mail indistinguishable from a spoofed phishing attempt.

Six months of silence: the disclosure timeline

The gap between private disclosure and public fix is the part UK buyers should sit with. BobDaHacker reported the flaw in early January 2026; by the time the story broke in late July, the endpoint was, in her words, still live. Tom's Hardware reports the app had been leaking data for over six months and that remediation only followed once the story went public — a pattern increasingly familiar in vendor breach response, where publicity does more to force action than private disclosure ever did.

This is not a niche or exotic finding. It sits alongside a well-documented run of API-driven exposures — Parler, Clubhouse and LinkedIn among them — all traced back to missing authorisation checks on APIs rather than any advanced attack technique, according to Cisco's API security guidance.

Why a leaky prayer app matters to UK security teams

It's tempting to file this under low-stakes novelty. It isn't. BobDaHacker's own framing is blunt: many Click to Pray users are older, less tech-literate, and highly trusting of anything appearing Vatican-branded — a demographic profile that makes a leaked email-and-name database a genuine "phishing goldmine." Combine that with genuine verification emails that already fail authentication checks, and attackers gain a template for near-indistinguishable spoofed messages.

For UK organisations handling any consumer-facing PII — charities, membership bodies, faith organisations, healthcare portals — the lesson translates directly. If your service holds names, emails and dates of birth for a trusting user base, an IDOR-class flaw isn't a compliance footnote; it's a direct enabler for social engineering at scale. Readers unsure where their own exposure sits should understand what constitutes a data breach under UK rules before assuming a leak like this wouldn't apply to them.

The bigger API security pattern UK buyers should recognise

The uncomfortable truth is that authentication and authorisation are not the same control, and this incident shows exactly why conflating them fails. Click to Pray's API almost certainly had some login flow for the app itself — the failure was that the backend never checked whether the logged-in user was entitled to the specific record being requested. That's an object-level authorisation gap, and it's precisely the category Cisco flags as recurring across major API breaches.

For procurement and audit teams, this argues for API testing that goes beyond checking whether an endpoint requires a token, and instead probes whether that token actually limits access to the caller's own data. Vendor due diligence, penetration testing scopes, and internal vulnerability management services should all explicitly include IDOR and object-level authorisation testing as a line item, not an afterthought.

What this means for UK procurement and breach-response readiness

Two failures compounded here: a technical one (no authorisation check) and a process one (no response to responsible disclosure for six-plus months). Both are fixable with the same discipline. UK buyers evaluating any third-party or in-house API-driven service should insist on evidence of a working vulnerability disclosure process, not just a policy document nobody actions.

Where a supplier can't demonstrate that, treat it as a risk signal equivalent to weak zero trust controls elsewhere in the estate. Building an internal capability that combines incident response planning with continuous managed detection & response monitoring means a silent vendor doesn't leave your organisation blind to exposure for half a year. And because IDOR-class breaches often precede secondary attacks like phishing or credential stuffing, pairing this with active ransomware protection and broader cyber security solutions closes the loop rather than treating the API bug as an isolated event.