TestersWiz · Production Readiness ReportSAMPLE REPORT
PlantPal
com.plantpal.app · version 1.4.2 · scanned 24 September 2026 · report TW-SAMPLE01
VERDICT
Fix before you release
Supabase service key shipped in the app (project qwxkzmhtr2plantpal01). Findings at this level expose data or privileged actions, or stop a store accepting the build, so fix them before you release.
1Critical
1High
2Medium
5Low
3Info
✓ 2 fixedsince 11 September 2026
Ready for Google Play?
2 things to fix before you submit. Checked against what the package shows. Only Google decides whether a build is accepted; this tells you what stands in the way.
- Fix first
Targets the Android version Google Play requiresTargets API 34. Google Play requires API 36 for new apps and app updates (since 31 August 2026). See finding #4.
- Ready
Is a release buildNot debuggable.
- To do
Permissions that may need a Play Console declaration2 permissions may need a declaration or review in Play Console (App content): READ_MEDIA_IMAGES, AD_ID. Declare each one you use, or remove the ones a library added that you do not. See findings #7, #8.
- Fix first
No critical or high security issues2 critical or high findings to fix before release. See findings #1, #2.
- To do
Data Safety form6 data types to declare, drafted from what the package shows. Add anything your own backend collects.
Summary
We analysed PlantPal 1.4.2, built with React Native (Expo). The analysis found 1 critical, 1 high, 2 medium, 5 low findings to act on, and set 4 aside with a stated reason (shown at the end). The most serious: Supabase service key shipped in the app (project qwxkzmhtr2plantpal01). This key bypasses row-level security. This is an automated static analysis: it cannot prove the absence of problems, and the section on what it could not check matters as much as the findings.
Application profile
What the package says about itself, before looking for problems.
Built withReact Native (Expo)
EngineHermes bytecode
Android APItargets 34 · min 24
Supabaseqwxkzmhtr2plantpal01
Firebaseplantpal-prod
Data-collecting SDKsGoogle Firebase Analytics, Sentry, Google AdMob
Where your own code isYour JavaScript/TypeScript is in assets/index.android.bundle (compiled to Hermes bytecode). Most of the Java in this app is React Native and library code.
Critical and high findings
| # | Severity | Finding |
|---|
| 1 | Critical | Supabase service key shipped in the app (project qwxkzmhtr2plantpal01) |
| 2 | High | OpenAI API key shipped in the app |
Your to-do list
Work through these in order.
Supabase service key shipped in the app (project qwxkzmhtr2plantpal01): Rotate it now: with the new API keys, delete this secret key in Supabase → Project Settings → API Keys and create a new one; with the legacy JWT keys, rotating means changing the project's JWT secret, which also replaces the anon key.
OpenAI API key shipped in the app: Revoke the key at the provider now, then call the provider from your server (or an Edge Function) and have the app call that instead.
Unencrypted HTTP is allowed to every server: Remove android:usesCleartextTraffic="true".
Targets Android API 34, below Google Play's current requirement of 36: Raise targetSdkVersion to 36.
Compared with your scan on 11 September 2026- 2 fixed: The app is built as debuggable; Content provider PlantProvider is open to every app
- 0 still open
- 1 new: OpenAI API key shipped in the app
What this scan did not check
Not tested- Your backend, APIs and servers: this scan reads the APK file only and connects to nothing.
- Runtime behaviour: the app was not installed or run, so nothing here shows what it does when used.
- Business logic and authorization: whether a signed-in user can reach another user's data depends on your backend.
- Code the app downloads or loads at runtime, including over-the-air updates (Expo Updates, CodePush) and remote configuration.
- Whether each finding is reachable in normal use: static analysis sees the code that exists, not the paths that run.
- Supabase project qwxkzmhtr2plantpal01: its row-level security, grants, functions and storage policies are what protect user data, and were not tested. Run the Database Security Audit on it.
- Firebase security rules (Firestore, Realtime Database, Storage): not visible in the APK and not tested.
- Native libraries (.so files): only their readable strings were searched; their compiled code was not analysed.
- Obfuscated or encrypted code, and code the decompiler could not recover, may hide patterns the analyzers look for.
What runtime or live testing could verify- Proxy the app's traffic and look for requests made over plain http://.
- Proxy the release build's traffic and check whether this host is contacted.
- Run `adb backup` or a device-to-device transfer on a test device and inspect what was copied.
- Run the release build on a real device through an intercepting proxy to see which hosts it actually contacts, and over what.
- Test your backend's access rules directly (for Supabase, run the Database Security Audit; then try requests with the anon key and as a second test user).
Methodology and limitations
- The APK you uploaded was checked to be a genuine Android package (by its contents, not its name) and scanned in an isolated environment with no internet access. It was never installed or run.
- It was decoded and decompiled, and open-source analyzers (apktool, jadx, mobsfscan, semgrep, gitleaks) read the manifest, the network security config, the decompiled code, resources, assets and the readable strings of compiled bundles.
- Every observation was graded by TestersWiz's deterministic rules: the same APK always produces the same findings, severities and verdict. Known legitimate behaviour of Android, React Native, Expo, Flutter and common libraries is downgraded or set aside with the reason stated, never hidden.
- Libraries are identified from version files and constants in the package; a library is only called vulnerable when its exact version matches a published advisory in a vulnerability database snapshot built into the scanner.
- Secrets are shown masked (a recognisable prefix and ****). Where an AI model was used, it wrote explanations of these findings from a redacted summary; it did not see your app and could not add, remove or re-grade anything.
Static analysis sees what is in the package, not what the app does when it runs, and it cannot see your servers or backend. It reports what the evidence supports and can be wrong in both directions: a finding may not be exploitable in practice, and a problem may exist that no rule detects.
Report TW-SAMPLE01. Tracker signatures: the εxodus database (exodus-privacy.eu.org), Open Database License 1.0.
This report is an automated static analysis of one Android application package (APK), as submitted. Findings and their severities come from automated, rules-based analysis; where an AI model is used, it only writes explanations of those findings. The report may contain false positives and may miss vulnerabilities. It is not a penetration test, an audit, a certification, or a guarantee that your app or its backend is secure, and it is not legal, regulatory or compliance advice. The Data Safety draft and Google Play notes are guidance based only on what is visible in the package: you remain responsible for your app, for your declarations to Google Play and any other store, and for any change you make because of this report. Test every change before you release it. Provided under the TestersWiz Terms of Service, which limit our liability.