Full Report
(Security) hole-ier than thou
Analysis Summary
# Incident Report: Click To Pray Data Exposure
## Executive Summary
The official papal prayer app, "Click To Pray," was found to have a critical security vulnerability exposing the personal information of over 700,000 registered users. The flaw, an Insecure Direct Object Reference (IDOR), allows unauthorized access to user names, email addresses, and locations. Despite being reported by an ethical hacker in January 2026, the vulnerability remained unpatched as of July 2026.
## Incident Details
- **Discovery Date:** January 3, 2026
- **Incident Date:** Ongoing (Identified publicly July 24, 2026)
- **Affected Organization:** Pope’s Worldwide Prayer Network
- **Sector:** Religious/Non-Profit
- **Geography:** Global (App available in seven languages)
## Timeline of Events
### Initial Access
- **Date/Time:** January 3, 2026 (Initial discovery and disclosure)
- **Vector:** Web API Vulnerability
- **Details:** Security researcher BobDaHacker identified that the application's API did not validate authorization levels when requesting user profiles.
### Lateral Movement
- **Details:** Not applicable in the traditional sense; however, the use of sequential numeric user IDs allowed for easy enumeration and bulk data collection across the entire user database.
### Data Exfiltration/Impact
- **Details:** Potential exposure of data for 719,517 accounts. Information includes email addresses, first and last names, country of origin, dates of birth, and account status.
### Detection & Response
- **Detection:** Discovered via manual security testing/ethical hacking.
- **Response Actions:** The researcher attempted to notify the organization on January 3. As of the publication date, the organization has reportedly not responded or remediated the flaw.
## Attack Methodology
- **Initial Access:** Exploitation of an Insecure Direct Object Reference (IDOR) bug.
- **Persistence:** Not required; the API remains publicly accessible.
- **Defense Evasion:** None; the system lacks rate limiting, allowing for rapid, automated scraping without triggering blocks.
- **Discovery:** Resource enumeration (incrementing sequential IDs).
- **Collection:** Automated scraping of the `api[.]clicktopray[.]org/user/users/{id}` endpoint.
- **Exfiltration:** Direct API responses in JSON or similar format.
- **Impact:** Mass data exposure and potential for high-success phishing campaigns.
## Impact Assessment
- **Financial:** Potential regulatory fines (e.g., GDPR) if applicable to the managing entity.
- **Data Breach:** Over 700,000 PII (Personally Identifiable Information) records.
- **Operational:** Low immediate disruption, but requires significant backend re-engineering.
- **Reputational:** High; the app is high-profile and endorsed by the Vatican, targeting a vulnerable and trusting demographic.
## Indicators of Compromise
- **Network:** Excessive GET requests to `https://api[.]clicktopray[.]org/user/users/` with incrementing numerical suffixes.
- **Behavioral:** High-volume traffic from single IP addresses targeting the user API; lack of SPF/DKIM/DMARC alignment in official correspondence (as noted by the researcher).
## Response Actions
- **Containment:** None currently reported by the organization.
- **Eradication:** Requires the implementation of an authorization layer to ensure users can only access their own ID.
- **Recovery:** Not applicable yet; the vulnerability is reportedly still live.
## Lessons Learned
- **The Importance of VDPs:** A lack of a clear Vulnerability Disclosure Program (VDP) or monitored security inbox led to a six-month delay in addressing a critical flaw.
- **API Security Basics:** Authorization checks must be performed on every request, especially when using predictable sequential IDs.
- **Email Trustworthiness:** Failure to implement proper email authentication (SPF/DMARC) makes an organization's legitimate communications indistinguishable from phishing.
## Recommendations
1. **Implement Access Control:** Ensure the API validates that the `user_id` requested matches the authenticated token of the requester.
2. **Use UUIDs:** Move away from sequential integer IDs for public-facing API endpoints to prevent easy enumeration.
3. **Rate Limiting:** Implement strict rate limiting on all API endpoints to prevent mass data scraping.
4. **Email Hardening:** Configure SPF, DKIM, and DMARC to protect users from phishing attempts and improve the deliverability of legitimate notifications.