Find the paths that could expose your users’ data.

Before you ship, review credential leaks, unsafe input handling and access rules in your React Native or Expo app. See the evidence, the possible damage and what to fix.

npx nativekeel security . --html security.html --fail-on high

Free, open source and local. No account. Your source stays on your machine. Add --offline to skip package and advisory lookups.

What could go wrong?

Credentials escape the app

Tokens and wallet secrets passed to telemetry, passwords embedded in URLs, secrets bundled in the app, unsafe storage and sensitive clipboard use.

Another user reaches private data

Open Firebase rules, overly broad writes and supported Supabase RLS policy mistakes. Deployed permissions and cross-account isolation still need runtime verification.

Untrusted data becomes code

WebView messages or fetched response bodies reaching eval/Function; traced text input or navigation values concatenated into SQLite query text.

Login or file sharing loses protection

OAuth code flows with PKCE explicitly disabled, implicit redirect tokens, and referenced FileProvider paths that cover entire private directories.

Native Android entry points and file paths

Six additional checks follow Java/Kotlin source: archive entry names reaching file writes, incoming nested Intents launched by an exported Activity, caller-selected WebView URLs, Intent text in local SQL, and caller-selected file reads or writes. Intent findings require an explicitly exported manifest entry without a declared permission and a matching source class; literal Gradle namespaces are supported. Merely having an exported Activity is not one of these flow findings.

Android 14 adds ZIP entry validation for apps targeting API 34+; Android 16 adds Intent launch protection. Findings describe these mitigations and ask for tests on supported devices. A file read is not automatically reported as exfiltration, and loading a URL is not automatically reported as native code execution.

A useful finding explains the attack conditions

Example: a WebView message reaches eval.

Evidence: the message value reaches a code-execution call, with file and line references.

Possible damage: page-controlled JavaScript runs in the app runtime.

Prerequisite: an attacker must control the page or inject script into it. This is not proof that your production page is compromised.

Fix and verification: use a fixed command allowlist with validated JSON; test locally with a harmless canary and confirm it is never executed.

Evidence over a reassuring score

The report separates static evidence, attacker prerequisites and verification steps. It includes existing TLS, dependency, secret and planted-malware checks. Export HTML for review, JSON for automation or SARIF for code scanning. Coding agents can call security_audit over MCP.

No matching findings is not proof of security. These checks do not run your app, test a deployed backend, analyze every data flow or certify MASVS compliance. The new flow checks follow short local aliases; complex validation, cross-file flows and skipped files can hide problems. Runtime and account A/B tests remain necessary.

How the new checks were verified

Each rule has positive and negative fixtures. A read-only pass over 922 repositories produced 13 source matches in 11 repositories after exclusions for public map identifiers, server/web code and cache-only sharing. These are review candidates, not confirmed breaches. No corpus application or malicious sample was executed.

The six native checks have positive and negative fixtures and CLI/MCP/report integration coverage. A read-only pass over 922 repositories produced no matching native findings. Guards, complex branches and unknown transformations may stop analysis; no match is not a passed security control. These new native flows currently cover Android, not iOS native flows, release binaries or deployed services.

Native Android definitions and limits · Read the rule definitions and limitations · Release history