The Vatican Prayer App Leak: How One Incrementing Number Exposed 700,000 Users — and Why "Collect Nothing" Beats "Secure Everything"

#security #privacy #android #webdev

Late last week, security researchers disclosed that Click To Pray, the Vatican's official prayer app, had been leaking the personal data of more than 700,000 users — names, email addresses, countries, birth dates and account roles. The flaw wasn't an exotic zero-day. Anyone could read another person's record simply by taking a user ID in a request and adding one to it, then one more, then one more. Malwarebytes and The Register both covered the disclosure, which traces back to ethical hacker BobDaHacker, who reported the issue in January 2026 and says it went unfixed for more than six months.

This is worth a few minutes of any developer's attention — not because a religious app is an easy target for a joke, but because the bug is one of the most common and most preventable classes of vulnerability on the web, and because the incident quietly makes an architectural argument that most of our industry keeps ignoring.

What actually went wrong: IDOR in one paragraph

The vulnerability is an Insecure Direct Object Reference (IDOR). It happens when an application exposes a direct handle to an internal object — most often a database primary key — in a request, and then trusts that handle without checking whether this user is allowed to see that object.

Concretely: an endpoint like GET /api/users/48213 returns user 48213's profile. If the server returns that record to anyone who asks, rather than confirming that the caller is user 48213 (or an admin), then user 48213's data is one HTTP request away from every other user. And because primary keys are usually sequential, an attacker doesn't even have to guess. They start at 1 and count. A short script walks the entire user table in minutes.

IDOR is boring, which is exactly why it keeps happening. It sits at number one on the OWASP API Security Top 10 as "Broken Object Level Authorization." There's no memory-corruption cleverness to it, no reverse engineering. It is a missing authorization check — one that should run on every object access and simply doesn't.

The lesson every backend developer should take away is the concrete one: never trust a client-supplied object reference. Authorize every object access against the authenticated caller, use unguessable identifiers (UUIDs) instead of sequential integers as a defense in depth, and test for IDOR explicitly — pull a token for user A, request user B's resources, and assert you get a 403, not a 200. If you own an API today, that test is worth writing before you finish reading this.

The bigger point: the data you never collect can't leak

Patching this specific bug is necessary and, as of the disclosure, done. But there's a second lesson underneath the first, and it's the one that rarely makes it into the incident write-ups.

Every field in that leak — the name, the email, the birth date, the country — existed because the app collected it, stored it on a server, and tied it to an account. That's the default shape of a modern app: create an account, sync everything to the cloud, keep it there indefinitely. It's a shape that produces convenience, and it produces a honeypot. The moment you hold 700,000 users' personal records in one place, you have created a target whose value grows with every signup, and you are now one missing authorization check away from exposing all of it at once.

There is a different default, and it's one we build around at Super Funicular with our Android app, Background Camera RemoteStream. The app turns a spare phone into a camera you can watch live and record from — and it does that without an account, without a cloud backend, and without tracking. Footage is stored locally on the device. There is no user table on our servers with your name and email in it, because there is no signup and no server-side profile in the first place.

That isn't a security feature bolted on after an audit. It's an architectural stance: the most reliable way to not leak user data is to not be holding it. You cannot have an IDOR bug that exposes 700,000 email addresses if you never collected 700,000 email addresses. You cannot suffer a breach of cloud-stored video if the video never left the phone. The attack surface that doesn't exist is the one you never have to defend.

This is the same principle privacy engineers call data minimization, and regulators increasingly write into law: collect only what you genuinely need, keep it only as long as you need it, and prefer designs where sensitive data stays on the user's device. For a camera app in particular — where the "data" is a live view of someone's home, office, or child's room — the stakes of getting this wrong are considerably higher than a leaked email list.

What to take from this

If you build APIs, treat the Vatican leak as a reminder to go add object-level authorization checks and an IDOR test to your suite this week. Sequential IDs plus a trusting endpoint is a breach waiting for someone to run a simple loop.

And if you're choosing tools — or designing your next feature — ask the harder question first: does this actually need an account and a cloud copy at all? Often the answer is no, and choosing "local-first, collect nothing" turns a whole category of breach headlines into something that simply can't happen to your users.

If you want to see what that looks like in practice, Background Camera RemoteStream is on Google Play — private by architecture, local storage, no account, no cloud, no tracking: