<meta http-equiv="Content-Security-Policy"> tag, and its
connect-src lists exactly what the app may reach.
connect-src 'self'). Nothing to allowlist beyond your own hosting origin.| Destination | Port | Purpose | Required? |
|---|---|---|---|
| Your hosting origin (the domain serving the app) | 443 | App shell, assets, on-device OCR model, and the /api sync relay when it is served same-origin | Yes |
*.stytch.com | 443 | Authentication: phone/email one-time codes and session issuance | Yes (sign-in fails without it) |
challenges.cloudflare.com | 443 | Cloudflare Turnstile person check on the sign-in text step. Loaded only on that step, and only in a build that sets VITE_TURNSTILE_SITE_KEY (the hosted product does). The server also calls it to verify the check | Yes in the hosted product (no sign-in code is sent without it) |
checkout.stripe.com | 443 | Payment page for Couple Vault Plus. The browser goes there only when a person chooses a plan; the app loads nothing from Stripe. Our server calls api.stripe.com, which is server egress, not the browser's | Only to buy a plan |
| Your sync-relay origin, if deployed on a separate domain | 443 | Encrypted vault sync. Not needed when the relay is same-origin at /api, which is the default deployment. | Only if separately hosted |
The relay receives ciphertext only; the encryption key never leaves the couple's devices.
The one exception carries no content: if a signed-in person turns on Share usage counts, the app also
sends allowlisted event names and a day to the same relay origin. Buying Plus sends the browser to Stripe's
checkout page and back; no vault content is involved. No other destination is involved.
Blocking *.stytch.com does not degrade gracefully: users cannot sign in, and an account is required
for a non-demo vault.
Only if a paired, signed-in person turns on Tell me when my partner changes something (off by default).
The app's page script contacts no new domain for this, so the Content-Security-Policy connect-src is
unchanged. Two other parties make the connections:
| Destination (server egress) | Port | Push service |
|---|---|---|
fcm.googleapis.com, android.googleapis.com | 443 | Chrome, Android and other Chromium browsers |
updates.push.services.mozilla.com | 443 | Firefox |
*.push.apple.com | 443 | Safari, and the app added to the Home Screen on iPhone and iPad |
*.notify.windows.com | 443 | Edge on Windows |
Each notification is one fixed sentence, encrypted to the receiving device, with no vault content. (The iPhone app uses Apple's push service instead of these hosts: see "The iPhone app" below.) If these hosts are blocked from the server, notifications do not arrive and nothing else is affected.
The iPhone app is the cloud build in an app. Its pages are bundled inside the app, so the app loads no page or script from the network, and it has no service worker. It needs these destinations:
| Destination | Port | Purpose | Required? |
|---|---|---|---|
ourcouplevault.com (the relay at /api) | 443 | Sign-in, encrypted vault sync, billing status and notification registration. The app reaches the relay at https://ourcouplevault.com/api and sends the header X-CV-Client: ios | Yes |
challenges.cloudflare.com | 443 | The Cloudflare Turnstile person check on the sign-in text step, as in the cloud build above | Yes (no sign-in code is sent without it) |
| Apple's own hosts for the App Store | 443 | Buying and restoring Couple Vault Plus. The iPhone connects to these hosts itself. Couple Vault does not control them. Apple publishes the list for managed networks | Only to buy or restore a plan |
Apple's push service (*.push.apple.com and the 17.0.0.0/8 network) | 5223, with 443 as a fallback | The iPhone keeps its own connection to Apple to receive notifications. Couple Vault does not open it, and the app's code contacts no new host for it. Apple publishes the current port list for managed networks | Only for notifications |
Two kinds of traffic are server-side and are not the iPhone's: our server sends each notification to
api.push.apple.com (port 443), and our server checks each purchase with Apple's App Store Server
API. If these hosts are blocked from our server, notifications do not arrive and a purchase is not applied. The
app sends the sign-in code to our server, which checks it with the identity provider.
Each notification is one fixed sentence with no vault content. The relay receives ciphertext only, as on the web. A fixed sentence and the iPhone's device token go to Apple for notifications, and Apple handles the payment for a purchase in the app.
| Destination | Port | Purpose | Required? |
|---|---|---|---|
| Your hosting origin (the domain serving the app) | 443 | App shell, assets, on-device OCR model, and the map basemap | Yes |
No analytics, pixels, fonts, or scripts are loaded from third parties. On-device OCR (Tesseract) and its language model are served from the app's own origin, not a CDN.
There is no map provider to allowlist. The Places screen draws a real map at real coordinates,
and its geometry ships inside the application: one static asset at
/basemap/world-50m.json (about 216KB brotli), served from the same origin as the app and cached by
the service worker. No map tiles are requested, from us or anyone else, at any zoom level. No place name or
coordinate is sent anywhere, and the app never asks the browser for the device's location.
If that asset is blocked or unavailable, the Places screen still works: it shows the saved places in their correct positions relative to one another, with a scale bar and a coordinate grid, and says plainly that the terrain could not be loaded. Nothing else on the screen is affected.
Only if the operator built with VITE_GOOGLE_CLIENT_ID set and a user chooses to connect their
Google Drive (off by default). When enabled, these additional origins are used:
| Destination | Port | Purpose | Required? |
|---|---|---|---|
accounts.google.com | 443 | Google sign-in (OAuth token model) | Only if Drive enabled |
content.googleapis.com | 443 | Google Identity Services (framed by the sign-in flow) | Only if Drive enabled |
www.googleapis.com | 443 | Drive appDataFolder read/write (encrypted blobs only) | Only if Drive enabled |
oauth2.googleapis.com | 443 | OAuth token revoke on disconnect | Only if Drive enabled |
Even when enabled, only encrypted ciphertext is uploaded; Google cannot read document contents.