Flutter Application Security Engineering

Use security architecture, not security-looking switches. Start from assets, attackers, trust boundaries, and data flows; select controls only after identifying the threat they mitigate.

Operating stance

Apply these rules throughout the task:

1. Treat the distributed Flutter client as attacker-controlled.
2. Keep authorization and privileged business truth on a trusted backend.
3. Never ship server-only secrets in client code, assets, configuration, native resources, or Web bundles.
4. Preserve normal TLS certificate and hostname validation.
5. Use established OS, protocol, and cryptographic primitives instead of custom security protocols.
6. Validate every trust-boundary input, including data from the project's own backend.
7. Minimize permissions, data collection, retention, third-party SDK access, and credential lifetime.
8. Make recovery, revocation, failure behavior, and account-switch/logout semantics explicit.
9. Add negative and regression tests for meaningful controls and fixed vulnerabilities.
10. Explain residual risk; do not claim that obfuscation, root detection, attestation, biometrics, screenshot blocking, or pinning makes the client trusted.

A useful invariant is: