The latest articles on DEV Community by Flutter Guard (@flutterguard). https://dev.to/flutterguard https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3686109%2Fb1d912c0-102a-4d5e-95a3-3f00c26b8358.png https://dev.to/flutterguard en Flutter Guard Tue, 30 Dec 2025 13:09:21 +0000 https://dev.to/flutterguard/i-shipped-my-firebase-key-heres-the-tool-i-built-so-you-dont-40p8 https://dev.to/flutterguard/i-shipped-my-firebase-key-heres-the-tool-i-built-so-you-dont-40p8 <p>You spent months building your Flutter app. QA passed. Users love it. You ship to production.</p> <p>Then a security researcher emails you: "Hey, I found your Firebase keys hardcoded in your app."</p> <h2> What Attackers See in a Built Flutter App </h2> <p>When you compile a Flutter app, you're creating a package that contains more than just your UI code. Here's what can leak:</p> <h3> 1. Hardcoded Secrets </h3> <ul> <li>API keys baked into Dart code</li> <li>Firebase credentials (database URLs, API keys, project IDs)</li> <li>OAuth client secrets</li> <li>Third-party service tokens</li> </ul> <p>These survive compilation and end up in your final build, readable by anyone who decompiles your app.</p> <h3> 2. Firebase Misconfigurations </h3> <ul> <li>Unrestricted database rules</li> <li>Public storage buckets</li> <li>Missing auth requirements</li> <li>Admin SDK credentials in client code</li> </ul> <h3> 3. Dangerous Permissions </h3> <ul> <li> <code>INTERNET</code> (required but often paired with risky perms)</li> <li> <code>READ_EXTERNAL_STORAGE</code> / <code>WRITE_EXTERNAL_STORAGE</code> without justification</li> <li> <code>ACCESS_FINE_LOCATION</code> when unnecessary</li> <li> <code>CAMERA</code> / <code>MICROPHONE</code> that raise privacy flags</li> </ul> <h3> 4. Debug Builds in Production </h3> <ul> <li>Leaving <code>debuggable=true</code> in AndroidManifest.xml</li> <li>Exposing dev endpoints</li> <li>Verbose error messages with stack traces</li> <li>Debug symbols that make reverse engineering easier</li> </ul> <h2> Why This Happens </h2> <p>Flutter's compilation process:</p> <ol> <li>Dart code → compiled native code</li> <li>Assets, configs, manifests → bundled as-is</li> <li>Strings, URLs, keys → often remain in readable form</li> <li>Tree-shaking doesn't remove hardcoded secrets</li> </ol> <p>You think you're safe because the code is compiled. But decompilation tools can extract:</p> <ul> <li>Asset files</li> <li>Android manifest permissions</li> <li>Compiled string literals</li> <li>Resource files and configs</li> </ul> <h2> How to Catch These Before Release </h2> <p><strong>Pre-release security checklist:</strong></p> <ol> <li>Never hardcode secrets—use environment variables or secure vaults</li> <li>Audit Firebase rules (assume your keys are public)</li> <li>Review AndroidManifest.xml for debug flags and excessive permissions</li> <li>Strip debug symbols from production builds</li> <li>Test your own app with decompilation tools</li> </ol> <p><strong>Or scan it automatically:</strong><br> I built <a href="https://flutterguard.dev/" rel="noopener noreferrer">FlutterGuard</a> after I shipped my Firebase key in production (true story—security researcher found it). It decompiles your Flutter app and shows you exactly what an attacker sees:</p> <ul> <li>Hardcoded secrets/URLs/Firebase configs</li> <li>Dangerous permissions and debug builds</li> <li>Clear, actionable report in ~3 minutes</li> </ul> <p><strong>Offer:</strong> 3 free scans/day, no card required → <a href="https://flutterguard.dev/" rel="noopener noreferrer">flutterguard.dev</a></p> <p>If you try it, tell me one thing to improve—I ship fixes same-day.</p> <p>Stay safe. Ship secure. 🔒</p> flutter security tooling saas