Shield · Mobile apps

Mobile apps

Shield scores the network behind each sensitive action in your iOS or Android app, the same way it does for a website: VPN, proxy, Tor, hosting and malicious networks, with a recommendation of allow, monitor, challenge or block. Your backend confirms the verdict before it acts.

How it works

Three steps

1In the Shield dashboard, create a mobile app site and register your app's id: the iOS bundle identifier, the Android applicationId, or both.

2Your app calls Shield once before each sensitive action, such as a signup, a login, a password reset or a checkout. Shield answers with a verdict.

3Your app sends the Shield session ID with the request to your backend. Your backend asks Shield about that session with the secret key (Server Verification) and allows, challenges or blocks.

The site key in your app is public, like any key shipped in an app. It identifies your app and proves nothing. Only the answer your server gets with the secret key counts.

Three ways to connect

The dashboard's Install page has each one with your key filled in

Your app	What to add
Native iOS (Swift)	A short helper file that posts to the Shield API. No package to install.
Native Android (Kotlin)	The same helper for Android, using coroutines and no other library.
WebView (Capacitor, Ionic, Cordova, a page in a native WebView)	The website script with `data-integration="webview"` and `data-app-id` (SDK 1.13.0 or later). Form detection and in-page enforcement work as on a website.

<script src="https://cdn.findip.net/shield/v1.js"
  data-site-key="pub_xxxxxxxxx"
  data-integration="webview"
  data-app-id="com.example.app"
  async></script>

What the app sends

Metadata only

Sent	Never sent
The app id, version and build	Anything the user typed: passwords, form values, messages
The OS and its version	Advertising IDs (IDFA, GAID) or any cross-app identifier
The device family (iPhone, iPad, Pixel), never the exact model	Contacts, location, photos, or any other device data
Locale and timezone	A device fingerprint
A session ID per app launch and a visitor ID kept in the app's own storage	Plain emails or user IDs (only hashes and encrypted values, if you identify users)
The event name, for example `login_attempt`

Shield reads the IP address from the network connection, never from the app. The full field list is in the Events reference.

For the App Store's App Privacy form and Google Play's Data safety form, the helper collects a device or other ID (the app-scoped visitor ID), app interactions (the event names), and app info (app and OS version). Purpose: fraud prevention and security. It is not used for tracking or advertising, and it is not linked to the user's identity unless you send identity yourself.

Verdicts in an app

The app reacts; the backend decides

`recommendation`	What to do
`allow`	Proceed.
`monitor`	Proceed; log it if you keep a review queue.
`challenge`	Your backend asks for its own step-up: a one-time code, a re-login, an email link.
`block`	Your backend refuses after verifying the session. The app shows a neutral "could not complete" message.

No answer from Shield (no network, a timeout) means unknown, never safe. Decide per action.

Refusals

Shown on the dashboard's Install page

Error	Fix
`app_mismatch` (403)	The app id is not registered for that platform. Add it under Settings → Apps & keys. Debug builds with an id suffix count as separate apps.
`integration_not_allowed` (403)	A website used an app site's key, or an app used a website's key. Each needs its own kind of site.
`daily_quota_exceeded` (429)	The site's daily quota is used up. Events are accepted again from 00:00 UTC.

Limits

Free Preview

The same quota as a website: 10,000 events a day per site. Send sensitive actions, not every screen.
One site holds up to 10 apps, so the iOS, Android and staging builds of one product share sessions, rules and alerts.
Device integrity checks (App Attest, Play Integrity) are not part of this release.