Amen to that fail: Holy app commits a mortal sin and exposes 700,000 users
The latest crossover between centuries-old institutions and modern software development is a masterclass in why not everything needs to be an app.
If you thought the industry had already peaked with Bluetooth-enabled water bottles and smart toasters, brace yourself. The Vatican built an official prayer app. It has over 700,000 users. And it has been leaking their personal data for more than half a year, since at least January 3, 2026, and likely earlier.
A Textbook Case of Insecure Architecture
You’d expect an organization with this kind of reach to have a competent dev team behind it. According to security researcher BobDaHacker, who found and ethically disclosed the issue, the app exposed the private data of nearly three-quarters of a million users for over six months.
It was reported in January. The response, as far as anyone can tell, was silence.
The core issue is what the security world calls an Insecure Direct Object Reference, or IDOR. In plain terms: the app’s access control was a velvet rope with no bouncer standing next to it.
Here’s how the app actually worked. When a user signs up for a Click to Pray account, the app assigns a sequential numeric user ID. The endpoint api.clicktopray.org/user/users/{id} returns user data for any account, not just your own, as long as you supply a valid five-digit ID. No authentication check. No authorization check. No ownership validation.
No authentication required. Users get a basic sequential number: 1, 2, 3, and so on. Ask the server for your own profile and it hands it over. Change the number by one digit and ask for someone else’s, and the server does exactly the same thing.
No rate limiting, either. There was nothing stopping anyone from writing a three-line script to count from 1 to 719,517 and download the first and last names, email addresses, birthdays, and locations of every user on the platform.
The verification flow made it worse. When you sign up, the server returns the account’s secret validation hash directly in the response. That means someone could create an account using a stranger’s email address and verify it themselves before the real confirmation email ever landed in that person’s inbox.
Why This Specific Leak Is Genuinely Dangerous
The demographics matter here. A prayer app built for a global religious community skews toward an older, highly trusting user base, many of whom aren’t running particularly cautious digital habits.
Imagine Grandma’s inbox next week: “URGENT MESSAGE FROM THE HOLY FATHER: Your soul is in arrears. Please click here to enter your credit card and buy three Hail Marys.”
She’s clicking that link.
That’s not a joke, it’s the actual risk. According to the FBI’s IC3 annual reports, elder fraud is a multi-billion dollar problem, and scammers specifically target older, less digitally literate individuals. A leak of 700,000 verified email addresses tied to a trusting, faith-based demographic is close to a purpose-built lead list for phishing operators.
The follow-on risk is obvious: a wave of convincing, personalized phishing attempts aimed at people who are statistically among the most likely to fall for them. That’s a real harm, not a punchline, and it’s the part of this story that actually matters most.
To make things worse, the app’s own automated emails are configured poorly enough that spam filters already flag them as spoofed. So the leaked data hands attackers a target list, and the legitimate app’s own emails already look like phishing to begin with.
The Broader Lesson
At some point, the industry-wide instinct to “build an app for everything” needs a second thought. Every additional app is additional attack surface, additional user data at rest, and additional code that needs someone competent maintaining it.
An IDOR bug like this one isn’t sophisticated. It’s the kind of thing a junior engineer should catch in code review. When it ships anyway, and stays live for six months after being reported, the failure isn’t really technical, it’s organizational: nobody owned the responsibility to fix it.
If your organization is sitting on a user base that skews vulnerable, whether that’s by age, trust level, or digital literacy, the bar for how carefully you handle access control should be higher, not lower. This is what that bar looks like when nobody clears it.
Worried about what’s exposed in your own user base right now?
