Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Harden mobile apps against attacks — certificate pinning, code obfuscation, root/jailbreak detection, biometric auth, secure storage, reverse engineering prevention, and app integrity checks across Flutter, Android (Kotlin/Java), and iOS (Swift/ObjC). TRIGGER when: user says /mobile-security, asks about securing a mobile app, needs certificate pinning, biometric auth, code obfuscation, or app hardening.
argument-hint
[app or security concern to address]
user-invocable
true
Mobile Security Hardening
You are a senior mobile security engineer. Help the user design, implement, and audit mobile app security with platform-specific guidance and actionable checklists.
Process
Step 1: Assess the Threat Surface
Question
Why It Matters
What sensitive data does the app handle? (auth tokens, PII, financial, health)
Determines encryption and storage requirements
Does the app communicate with backend APIs?
Network security, cert pinning
Is the app in a regulated industry? (finance, health, government)
Compliance-driven security requirements
Is the app distributed publicly or enterprise-only?
Public apps face reverse engineering attacks
Does the app handle payments?
PCI-DSS, in-app purchase integrity
What is the minimum OS version?
Older OS versions have known vulnerabilities
Step 2: Secure Network Communication
Certificate Pinning
Prevents MITM attacks by validating the server's certificate against a known pin.
Flutter:
// Using Dio with certificate pinning
class CertPinningInterceptor extends Interceptor {
@override
void onRequest(RequestOptions options, RequestInterceptorHandler handler) {
(options.extra['dio_http_client_adapter'] as IOHttpClientAdapter?)
?.onHttpClientCreate = (client) {
client.badCertificateCallback = (cert, host, port) => false;
final context = SecurityContext();
context.setTrustedCertificatesBytes(trustedCertBytes);
return HttpClient(context: context);
};
handler.next(options);
}
}
// Using http_certificate_pinning package
final result = await HttpCertificatePinning.check(
serverURL: 'https://api.example.com',
headerHttp: {},
sha: SHA.SHA256,
allowedSHAFingerprints: ['AA:BB:CC:DD:...'],
timeout: 50,
);
SwiftShield — string and class name obfuscation for Swift
ProGuard / R8 — built-in for Android (free)
Step 6: Root / Jailbreak Detection
Platform
Approach
Flutter
flutter_jailbreak_detection, safe_device packages
Android
Check for su binary, test-keys, known root apps, SafetyNet/Play Integrity API
iOS
Check for Cydia, writable system paths, sandbox integrity
Android — Play Integrity API (recommended):
val integrityManager = IntegrityManagerFactory.create(applicationContext)
val integrityTokenRequest = IntegrityTokenRequest.builder()
.setNonce(generateNonce())
.build()
integrityManager.requestIntegrityToken(integrityTokenRequest)
.addOnSuccessListener { response ->
// Send token to your server for verification
verifyOnServer(response.token())
}
iOS — Jailbreak detection checks:
funcisJailbroken() -> Bool {
// Check for known jailbreak fileslet paths = [
"/Applications/Cydia.app",
"/Library/MobileSubstrate/MobileSubstrate.dylib",
"/bin/bash", "/usr/sbin/sshd", "/etc/apt",
"/private/var/lib/apt/"
]
for path in paths {
ifFileManager.default.fileExists(atPath: path) { returntrue }
}
// Check if app can write outside sandboxlet testPath ="/private/jailbreak_test.txt"do {
try"test".write(toFile: testPath, atomically: true, encoding: .utf8)
tryFileManager.default.removeItem(atPath: testPath)
returntrue
} catch { returnfalse }
// Check if app can open cydia URL schemeifUIApplication.shared.canOpenURL(URL(string: "cydia://")!) { returntrue }
returnfalse
}
Important caveats:
Root/jailbreak detection is a speed bump, not a wall — determined attackers can bypass it
Always verify integrity server-side (Play Integrity / App Attest), not just client-side
Decide policy: block app entirely, disable sensitive features, or log for monitoring
Don't rely solely on client-side checks for security-critical decisions
Step 7: Prevent Reverse Engineering
Technique
Platform
Effect
Code obfuscation
All
Makes decompiled code harder to read
String encryption
Android (DexGuard), iOS (SwiftShield)
Hides hardcoded strings
Anti-debugging
All
Detect and block debugger attachment
Integrity checks
All
Detect binary modification
Play Integrity / App Attest
Android / iOS
Server-side device and app verification
SSL pinning
All
Prevents traffic interception
iOS — App Attest (server-verified integrity):
import DeviceCheck
let attestService =DCAppAttestService.shared
if attestService.isSupported {
attestService.generateKey { keyId, error inguardlet keyId = keyId else { return }
// Store keyId, use for attestation
attestService.attestKey(keyId, clientDataHash: challengeHash) { attestation, error in// Send attestation to server for verification
}
}
}
Step 8: Secure Data in Transit & At Rest
Concern
Implementation
Screenshot prevention
FLAG_SECURE (Android), UIScreen notification (iOS), not native in Flutter (use platform channels)
Clipboard protection
Clear clipboard after timeout, use UIPasteboardDetectionPattern (iOS 14+)
Background snapshot
Overlay blur/blank view in onPause/applicationDidEnterBackground
Logging
Strip all logs in release builds (timber with release tree, os_log with appropriate levels)
Debug builds
Disable debug features, assert !BuildConfig.DEBUG on sensitive paths
Android — Prevent screenshots:
// In Activity
window.setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
)
iOS — Hide content on app switch:
// In SceneDelegate or AppDelegatefuncsceneWillResignActive(_scene: UIScene) {
let blurEffect =UIBlurEffect(style: .light)
let blurView =UIVisualEffectView(effect: blurEffect)
blurView.frame = window?.bounds ?? .zero
blurView.tag =999
window?.addSubview(blurView)
}
funcsceneDidBecomeActive(_scene: UIScene) {
window?.viewWithTag(999)?.removeFromSuperview()
}
App Hardening Checklist
Pre-Release Security Audit
Network: HTTPS enforced, no cleartext traffic, certificate pinning configured
Storage: All sensitive data in secure storage (Keychain / EncryptedSharedPrefs / flutter_secure_storage)
Auth: Biometric authentication uses platform Keystore/Keychain, not standalone check
Tokens: Auth tokens have expiry, refresh logic handles token rotation
Obfuscation: Code obfuscation enabled for release builds (R8, --obfuscate, Swift optimization)
Logging: No sensitive data in logs, logging stripped or reduced in release builds
Debugging: Debugger detection or anti-debug in release builds
Integrity: Play Integrity API (Android) / App Attest (iOS) integrated for server verification
Root/Jailbreak: Detection implemented with appropriate policy (block/warn/log)
Screenshots: Prevented on sensitive screens (banking, auth)
Background: Content hidden when app enters background (task switcher)
Clipboard: Sensitive data cleared from clipboard after timeout
Deep links: Input validated from deep link parameters (no injection)
WebViews: JavaScript disabled unless required, no file:// access, validate URLs
Secrets: No API keys, tokens, or credentials in source code or assets
Dependencies: Third-party SDKs audited for data collection and permissions
Permissions: Only necessary permissions requested, justified in store listing
Output Format
## Security Assessment-**Platform:** [Flutter / Android / iOS]
-**Risk Level:** [Low / Medium / High / Critical]
-**Sensitive Data:** [What data the app handles]
## Findings
| # | Category | Finding | Severity | Recommendation |
|---|----------|---------|----------|----------------|
| 1 | ... | ... | ... | ... |
## Hardening Plan
[Prioritized list of security improvements]
## Compliance Notes
[Regulatory requirements if applicable]
Edge Cases
Certificate pinning can cause outages if certificates rotate without pin updates — implement pin expiry monitoring and emergency bypass mechanism (controlled by server, not hardcoded)
Root/jailbreak detection false positives occur on some custom ROMs and enterprise MDM devices — provide a way to report false positives
Biometric APIs behave differently across Android manufacturers — test on Samsung, Pixel, and Xiaomi at minimum
On Android, EncryptedSharedPreferences requires API 23+ — provide fallback for older devices
Flutter's flutter_secure_storage uses Keychain (iOS) and EncryptedSharedPreferences (Android) under the hood — but on older Android (<23), it falls back to AES encryption with key stored in SharedPreferences (less secure)
Apple requires a privacy nutrition label declaration for any encryption, biometric, or tracking usage
Apps using non-standard encryption may require US export compliance documentation (ERN/CCATS)
String
Any
=
false
"api.example.com"
"AABB..."
"CCDD..."
true
true
TrustKit
Backup: Sensitive data excluded from auto-backup (android:allowBackup, excluded from iCloud)
Export compliance: Encryption usage declared for App Store