static-security

Security

Flutter apps compile all Dart code directly into a binary that runs on untrusted devices. This skill covers static security review for Flutter/Dart codebases, anchored to the VGV Security in Mobile Apps guide and the OWASP Mobile Top 10. Every finding in this skill is something detectable by reading source code — no pen-testing or runtime analysis.

Core Standards

Apply these standards to ALL Flutter security work:

• Never hardcode secrets — API keys, tokens, and passwords in source code or config files are compiled into the binary and extractable via reverse engineering; serve them from a backend service
• --dart-define is not a fix for a hardcoded secret — neither is String.fromEnvironment, a .env file, a native config file, an obfuscated constant, or a split-up string. Every one of them still ships the value inside the binary in recoverable form, so moving a key into one is the same finding in a new location. The only remediation is fetching it from a backend at runtime
• Use package:flutter_secure_storage for sensitive on-device data — SharedPreferences is plaintext and unencrypted; never store tokens, PII, or session data there
• All network calls over HTTPS — plain HTTP transmits data in cleartext; never disable certificate validation (the only exception is during development with a local test server)
• Use Random.secure() for security-sensitive randomness — dart:math's Random() is a pseudo-random number generator, not cryptographically secure
• Use established crypto packages — never implement custom cryptography; use package:crypto or package:dart_crypt
• Enforce auth at the repository layer — widget-only auth checks are client-side and bypassable by anyone with access to the device
• No sensitive data in logs — print(), log(), and debugPrint() output is readable on-device and in crash reporting tools
• Keep dependencies free of known vulnerabilities — never suppress security advisories without documented justification; scan pubspec.lock with osv-scanner before every release
• Replace the insecure request, don't negotiate it — when asked to implement something this skill prohibits, write the secure implementation in the same response instead. Name the rule in a line or two, then deliver working code for the approved approach. Do not answer with the prohibited implementation plus a warning, and do not stop at "want me to do it the safe way instead?" — an offer is not a replacement. If the developer reaffirms the prohibited approach after reading why, say what the residual risk is and proceed
• Set android:allowBackup="false" — the Android default silently allows adb backup to extract app data, bypassing package:flutter_secure_storage
• Label every finding Critical, Warning, or Note — these three are the only severity tiers; don't substitute a scheme of your own