Full Report
A popular Vatican website and mobile app has been leaking hundreds of thousands of users’ names and email addresses. “Click to Pray” is the Vatican’s official prayer app. Users can sign up for access to daily prayers, and a steady stream of papal content on their phones or computers. It’s available on iOS and Android,…
Analysis Summary
# Incident Report: Exposure of Vatican "Click to Pray" User Data
## Executive Summary
A white-hat researcher discovered a critical Insecure Direct Object Reference (IDOR) vulnerability in the Vatican’s official "Click to Pray" application. This flaw allowed unauthorized access to an exposed API endpoint, potentially leaking the personally identifying information (PII) of over 700,000 global users and organizational employees. The incident highlights the risks associated with insecure API design in high-profile mobile and web applications.
## Incident Details
- **Discovery Date:** January (Year not specified, reported July 28, 2026)
- **Incident Date:** Ongoing until discovery/remediation
- **Affected Organization:** The Pope’s Worldwide Prayer Network (Vatican)
- **Sector:** Religious/Non-Profit
- **Geography:** Global
## Timeline of Events
### Initial Access
- **Date/Time:** January
- **Vector:** Insecure API Endpoint
- **Details:** Researcher "BobDaHacker" identified that clicktopray[.]org hosted an unauthenticated API endpoint that did not require authorization to query user records.
### Lateral Movement
- **N/A:** The vulnerability allowed for direct data harvesting via the API without the need for traditional lateral movement within the network.
### Data Exfiltration/Impact
- **Details:** The vulnerability exposed names, email addresses, and account details of over 700,000 users worldwide, as well as internal data regarding active employees of the Pope’s Worldwide Prayer Network.
### Detection & Response
- **Discovery:** Discovered by independent white-hat hacker "BobDaHacker" during a security review.
- **Response actions taken:** The researcher contacted the organization to report the IDOR vulnerability (specific mitigation dates were not provided in the summary article).
## Attack Methodology
- **Initial Access:** Exploitation of an Insecure Direct Object Reference (IDOR) vulnerability.
- **Persistence:** Not applicable; access was available as long as the API remained public and unauthenticated.
- **Privilege Escalation:** Broken Object Level Authorization (BOLA) allowed a standard guest to access data intended for administrators or the users themselves.
- **Defense Evasion:** The "attack" utilized legitimate API calls, making it difficult to distinguish from normal traffic without behavioral rate-limiting.
- **Discovery:** Automated or manual querying of API endpoints via a web browser or tool like Burp Suite.
- **Collection:** Bulk querying of the exposed API to aggregate user PII.
- **Exfiltration:** Standard HTTP GET requests to the vulnerable endpoint.
- **Impact:** Massive leak of PII affecting a global user base.
## Impact Assessment
- **Financial:** Undisclosed; potential costs related to remediation and compliance.
- **Data Breach:** Exposure of names and email addresses for ~700,000+ individuals.
- **Operational:** Potential suspension of app features during patching.
- **Reputational:** Significant public scrutiny for the Vatican's official digital platform regarding user privacy.
## Indicators of Compromise
- **Network indicators:** Requests to `clicktopray[.]org` targeting specific user-ID paths via API without valid session tokens.
- **Behavioral indicators:** Unusual spikes in traffic to API endpoints from single IP addresses (scraping behavior).
## Response Actions
- **Containment measures:** Closure or securing of the specific API endpoint.
- **Eradication steps:** Implementation of proper authentication and authorization checks for all API calls.
- **Recovery actions:** Verification of data integrity and security audit of the mobile app and web infrastructure.
## Lessons Learned
- **API Security:** APIs are often the weakest link in modern applications; they must be secured with the same rigor as traditional web interfaces.
- **Authorization vs. Authentication:** Simply checking if a user is "logged in" isn't enough; the system must verify if the user has the right to access the specific object requested.
## Recommendations
- **Implement Robust Authorization:** Use "Least Privilege" principles for all API endpoints; ensure every request validates the user's right to access the requested ID.
- **Security Auditing:** Conduct regular penetration testing and vulnerability scans with a focus on OWASP Top 10 API Security Risks.
- **Rate Limiting:** Implement rate limiting on API endpoints to prevent bulk data harvesting/scraping.