npx shadcn@latest add https://www.vengenceui.com/r/animated-button.json
top of page
Dc Cybertech logo
Search

Sacred Intentions, Exposed Records: How an IDOR Flaw Leaked 700,000 Accounts on the Pope's Official Prayer Platform

In the digital era, even spiritual devotion has found a home on smartphone screens. Millions of faithful individuals across the globe regularly turn to mobile applications to share intentions, coordinate prayer chains, and connect with their religious communities. However, a major cyber security failure in one of the most prominent religious platforms in the world has revealed that digital faith can carry significant privacy risks.


A security flaw in Click to Pray, the official prayer application and online platform of the Pope, has exposed personal data from over 719,000 accounts. The vulnerability left sensitive personally identifiable information, including full names, birthdates, email addresses, and country locations, open to anyone with a standard web browser. Despite responsible disclosure efforts initiated early in the year, the flaw remained unpatched for months, leaving hundreds of thousands of users unknowingly exposed to potential exploitation.


The Scope of the Exposure

Click to Pray serves as the official platform for the Pope's Worldwide Prayer Network. Designed to unite Catholic believers globally in daily prayer, the platform is available via dedicated mobile applications on iOS and Android as well as through a web portal. It encourages users to create profiles, publish prayer intentions, and follow monthly themes specified by the Vatican.


According to security findings first highlighted by white-hat security researcher BobDaHacker and verified by independent reporting from Tom's Hardware and Dark Reading, the platform contained an unauthenticated API endpoint. This endpoint leaked the record details of registered users across the entire platform.


The total tally of exposed accounts exceeds 719,000 unique records. Among the details made publicly accessible through this system flaw were:

  • Full names (first and last names provided during account creation)

  • Registered email addresses in plain text

  • Dates of birth

  • Country of origin and country of residence

  • Internal platform roles, such as flags identifying administrator or staff accounts


While the leak did not include financial details, credit card records, or encrypted account passwords, experts warn that the exposure of basic personal data remains a major threat vector.


Anatomy of an IDOR Vulnerability

The security failure in Click to Pray belongs to a well-known category of web flaws known as Insecure Direct Object Reference, or IDOR. IDOR is a subcategory of broken access control, which has consistently ranked at the top of the OWASP Top 10 list of web application security risks.


Put simply, an IDOR flaw occurs when an application receives a request from a user specifying an internal database object identifier, such as a numerical user ID, and returns the requested data without checking whether the requester has permission to view it.


In a properly secured application, when a user requests profile information, the server checks two things:

  1. Authentication: Is the requester logged in, and who are they?

  2. Authorisation: Does this logged-in user have permission to access record number 12345?


In the case of Click to Pray, the backend API handled user requests without enforcing the second step. In fact, the endpoint did not even require users to be logged in at all.

Furthermore, the user identifiers assigned by the Click to Pray database were sequential integers. An attacker or automated script could start at user ID number one and increment the counter sequentially up to 719,000. By making basic web requests to the exposed API URL for each consecutive number, an observer could collect the entire user database without triggering any authentication prompts.


The issue was compounded by a total lack of rate limiting. Standard web APIs typically employ rate-limiting mechanisms to restrict the number of queries a single IP address can make within a given timeframe. Without rate limits, an automated script could harvest thousands of records per minute directly through a browser or command-line script without being throttled or blocked.



Months of Silence Following Disclosure

The vulnerability was first discovered in January by BobDaHacker, a white-hat security researcher and privacy advocate. Adhering to standard ethical disclosure practices, BobDaHacker sought to notify the maintainers of the platform privately before publishing any details.


According to statements made by the researcher, they reached out to nine different individuals and contact channels associated with the application and its parent organisations in an effort to secure the bug responsibly. Despite these repeated attempts over a period of six months, the security reports went unacknowledged, and the backend vulnerability remained fully active on the live internet.


Frustrated by the lack of response and concerned that the data remained open to malicious scraping, BobDaHacker eventually published a summary of the flaw to warn users of the ongoing risk.


In a public message directed at the application's maintainers, BobDaHacker expressed disappointment over the ongoing silence:


"To Click to Pray: Your app is endorsed by the Pope," BobDaHacker wrote. "Hundreds of thousands of faithful users trusted you with their email addresses when they signed up to pray together. Fix the IDOR...Your users deserve better."

Independent security publications, including Dark Reading, subsequently tested the endpoint and confirmed that the vulnerability was still live at the time of their reporting. Exploiting the flaw required zero advanced hacking tools, requiring only a standard web URL entered into a standard web browser.


The Real-World Risks of Exposed Prayer Data

At first glance, some might assume that leaking names and email addresses is relatively harmless compared to losing bank credentials, payment card numbers, or government identification identifiers. Security professionals caution that this perspective understates the utility of personal data in modern cyber attacks.


The primary danger arising from a breach of this nature is highly targeted spear phishing. Generic spam emails often fail because they lack context and rely on broad, impersonal messaging. However, when an attacker possesses a victim's full name, email address, country of residence, and the knowledge that they actively use an official Vatican prayer application, the capability to craft convincing fraudulent messages increases dramatically.


Consider potential scenarios enabled by this dataset:

Vatican-Themed Phishing Schemes

Attackers can send emails that closely mimic official communications from the Vatican, the Pope's Worldwide Prayer Network, or Click to Pray administrators. These emails might claim that the user's account requires urgent verification, request donations for specific papal charitable initiatives, or invite the recipient to participate in exclusive digital prayer events. Because the email addresses the victim by their real name and refers to an app they actually use, recipients are much more likely to trust the message, click malicious links, or enter credentials on fraudulent login pages.


Impersonation and Social Engineering

Armed with location data and full names, scammers can target individuals across social media platforms or other communication channels. Attackers can pose as local church leaders, community coordinators, or fellow prayer network participants to build trust before launching secondary scams.


Risks to Vulnerable Populations and Sensitive Regions

Religion can be a sensitive topic depending on global geography. In countries where religious practice is heavily monitored, restricted, or actively persecuted by state actors or extremist groups, public exposure of an individual's active participation in a Christian prayer network can carry serious physical safety risks. An unauthenticated endpoint that reveals citizens' names, birthdates, and countries of residence alongside their religious affiliation presents a distinct privacy hazard for users living in politically delicate environments.


Executive and Staff Targeting

The inclusion of role flags in the API output added another layer of risk. By filtering for accounts marked with staff or administrator status, malicious actors could easily compile a directory of internal users tied to the platform's administration. These high-value accounts represent prime targets for credential harvesting and network intrusion attempts aimed at gaining deeper access to the Vatican's digital infrastructure.


Why IDOR Flaws Persist in Modern Software

The occurrence of an IDOR flaw on an official, high-profile app highlights a pervasive issue within software engineering. Despite being well understood in cyber security circles for decades, broken access control continues to top vulnerability charts.

To understand why these bugs remain so common, it helps to examine how modern web development frameworks operate.


Most contemporary web development tools and frameworks come with built-in mechanisms for authentication. When a developer builds an application using popular frameworks, features like user login, password hashing, session management, and token verification are frequently handled automatically or require minimal configuration. As a result, ensuring that a user is who they claim to be is relatively straightforward.


Authorisation, however, is a different challenge. Frameworks rarely know the specific business logic of an application. A framework cannot automatically infer whether User A should be allowed to view Document B or Profile C. That logic must be explicitly written by human developers for every single API endpoint.


When software development teams operate under tight deadlines, lack formal security training, or assume an API endpoint will only be accessed by their own front-end mobile code, authorisation checks are frequently omitted. Developers often fall into the trap of assuming that if a URL or endpoint is not explicitly published or linked on a website homepage, nobody will find it. In security, this mistake is known as security through obscurity, and it consistently fails because security researchers and automated tools routinely probe web applications to map out hidden or unlinked endpoints.


In the case of Click to Pray, the API endpoints were designed to fetch user details to display profiles within the app UI. The developers built the data retrieval function but neglected to verify whether the incoming request originated from an authorised session belonging to that specific user or an administrator.


The Vatican's Digital Journey and Security Precedents

The Click to Pray platform is part of a broader, multi-year strategy by the Vatican to embrace digital communication technologies and reach younger generations of believers worldwide.


Launched globally around 2018 and expanded significantly ahead of World Youth Day events, Click to Pray was designed as the official digital prayer hub for the Holy See. The application allows users to post their own prayers, read prayers written by others, and follow the personal prayer intentions posted directly on behalf of the Pope.


However, this is not the first time that digital initiatives connected to the Vatican have faced scrutiny over security vulnerabilities. In 2019, the Vatican launched an interactive smart rosary device called the eRosary, designed to be worn as a bracelet and synced with a companion mobile app. Within days of its release, security researchers discovered a critical vulnerability in the eRosary application. The flaw allowed attackers to take over user accounts without needing a password, simply by knowing the victim's email address. Fortunately, that vulnerability was patched quickly after public reporting.


The contrast between the swift resolution of the 2019 eRosary issue and the prolonged inaction surrounding the Click to Pray IDOR flaw highlights a persistent challenge faced by non-profit, faith-based, and institutional organisations. Many religious institutions manage complex, global digital footprints with large user bases, but they often rely on third-party agencies, contractors, or limited internal IT teams that lack dedicated, continuous cyber security resources or formal vulnerability management programmes.

Without dedicated security teams to monitor intake channels, security disclosures sent by independent researchers can easily end up ignored in generic contact form inboxes or spam folders, leaving known vulnerabilities active for extended periods.


How Users Can Protect Themselves

While end users cannot patch security vulnerabilities on remote application servers, there are several practical habits that individuals can adopt to minimise their exposure when registering for online services and mobile applications:


1. Minimise Data Footprints at Sign-Up

When creating accounts on lifestyle, religious, or community platforms, avoid providing unnecessary personal information. If a field such as birthdate or middle name is not strictly mandatory for the service to function, leave it blank or use generic information.


2. Use Email Masking and Relays

Modern operating systems and privacy tools offer email relay features, such as Apple's Hide My Email or Firefox Relay. These services generate unique, random email addresses for every app or website registration, forwarding incoming messages to your true inbox. If an application suffers a data breach, the exposed email address is merely a disposable alias that can be deactivated at any time without compromising your primary email address. Reporting from security analysts indicated that Click to Pray users who signed up using Apple's Hide My Email feature remained shielded from direct identification in this breach.


3. Adopt Pseudonyms for Public Profiles

Unless an account strictly requires legal name verification, consider using a pseudonym or first name only. Combining a pseudonym with a masked email address ensures that even if an underlying database leaks through an unauthenticated API, the records cannot be easily linked back to your offline identity.


4. Maintain Vigilance Against Unsolicited Messages

Users of Click to Pray should exercise heightened caution regarding any emails, messages, or notifications claiming to come from the Vatican, Click to Pray, or related religious organisations. Never click on links within unexpected emails, and always verify sender addresses carefully. If a message asks for account verification, password resets, or financial contributions, navigate directly to the official website through a separate browser window rather than clicking email links.


Lessons for Application Developers and Organisations

The Click to Pray incident offers several clear lessons for software engineering teams, particularly those building platforms for institutional, non-profit, or religious entities:

  • Enforce Object-Level Access Control: Every API route that returns user data must verify that the requesting session has explicit authorisation to view that specific record.

  • Randomise Object Identifiers: Avoid using simple, sequential integers for primary keys exposed in public APIs. Using Universally Unique Identifiers (UUIDs) makes sequential harvesting of records significantly harder, providing an additional layer of defense in depth.

  • Implement Global Rate Limiting: Restrict the rate of requests per IP address or session across all public endpoints to prevent automated scraping tools from enumerating database records.

  • Establish Clear Vulnerability Disclosure Channels: Organisations must maintain a dedicated, easy-to-find security contact address (such as security@domain.com or a security.txt file on their web domain). Inquiries sent to security channels should be monitored continuously by qualified personnel who can triage reports and coordinate patches.


As digital technology becomes further integrated into daily spiritual life, platforms like Click to Pray carry a significant duty of care. When users download an app endorsed by an institution as prominent as the Vatican, they place a high degree of trust in the platform's stewards.


Exposing the personal details of over 700,000 faithful users through a basic, preventable coding error, and leaving that leak open for months after receiving explicit warnings, represents a significant breakdown in stewardship. For the digital ecosystem to remain safe for believers worldwide, software security can no longer be treated as an afterthought or an optional luxury. Protecting user data is not just a technical requirement, it's an essential ethical responsibility.

 
 
 

Comments


bottom of page