Reacting to threats
Rampart reports; your app decides. Recommended reactions by risk.
Rampart never terminates your app. That keeps false positives from locking real users out, and it keeps the decision where the context is: your product and your backend.
Event shape
type ThreatEvent = {
id: ThreatId; // e.g. 'privilegedAccess'
confidence: 'low' | 'medium' | 'high';
evidence: string[]; // stable codes, never personal data
platform: 'ios' | 'android';
detectedAt: number; // epoch ms
};Recommended reactions
| Situation | Suggested reaction |
|---|---|
tampered, hookingFramework or debuggerAttached at high confidence | Treat the session as untrusted: block payments and data export, require server-verified attestation, log to your backend. |
privilegedAccess, unlockedBootloader, emulator | Allow browsing, but require a passing Play Integrity / App Attest check before sensitive actions. |
overlay, accessibilityRisk, screenCapture, untrustedKeyboard | Turn on the matching helper for sensitive screens, warn the user, avoid showing one-time codes or full card/health data. |
cloneOrVirtualSpace, untrustedInstaller | Ask the user to install from the official store; bind sessions to attestation. |
mockLocation, timeSpoofing | Do not trust client location or time for business rules; use your server's values. |
systemVpn, usbDebugging, developerMode | Usually informational. Many legitimate users have these on. |
Rules of thumb
- Never decide on money or regulated data from a client signal alone. Combine it with a server-verified result.
- Prefer degrading to blocking. Hide the risky feature, keep the rest of the app usable.
- Tell the user what to do, in plain language, in their language (including Arabic/RTL).
- Log evidence codes to your backend so you can tune reactions with real data.