The React Native Developer's Security Guide

Stephan W. — Tue, 25 Aug 2026 18:09:18 +0000

(Work in progress — same as the project it's about. More on that below)

Almost everything written about React Native security is about protecting your users: the shipped app, the phone it runs on. Almost nothing is written about protecting you, the React Native developer.

A React Native project is at least five distinct programming runtimes stitched together. Most developers can name one. The primary target has already shifted: it's no longer your customer, but you and your CI. Your MacBook's security model was never built to protect developers from their own tech stack.

You're the one holding the npm publish token, the GitHub PAT, the iOS distribution cert, the Android upload keystore, the App Store Connect key, and (increasingly) an AI agent with shell access.

Your MacBook is not a walled garden for your own repo

yarn install runs untrusted code with your full user privileges. No sandbox, before you've read a single line of it. It can read ~/.ssh, your keychain, every .env file on disk — the single most exploited primitive in the JS supply chain, and it's on by default.
metro.config.js, babel.config.js, app.config.js aren't config: they're Node programs that execute on your machine every time you start the bundler. A malicious Babel plugin runs at build time and controls your app's AST on the way into the bundle. Expo config plugins go further; they can silently edit project.pbxproj and inject a persistent build script that never shows up in a diff.
Your Podfile is a Ruby program with shell access, evaluated at pod install. Its script_phase hook doesn't just run once — it injects a build-phase script that fires on every future build, including your CI, with your release credentials.
Xcode scheme pre-actions run before the build even starts, so they fire even when the build fails. They're also buried three menus deep somewhere almost no developer has ever opened. A default RN project has zero of these. Any hit is a five-alarm fire.
build.gradle executes on sync, not on build: opening the project, switching branches, even a dry run triggers it, handing an attacker the entire JVM standard library instead of just a shell.
Opening the folder in your editor can be the compromise. "runOn": "folderOpen" in .vscode/tasks.json is zero-click, invisible code execution. Your AI agent's MCP servers are worse: over 30% of surveyed MCP servers carry an exploitable vulnerability, and "tool poisoning" has already been used to trick agents into reading a user's private SSH key.

None of this is hypothetical. nx/s1ngularity turned install hooks into an AI-agent-assisted credential hunt. Shai-Hulud self-propagated through compromised npm packages. GlassWorm hid its payload in invisible Unicode that renders as nothing (in your editor, in the GitHub diff) and still compromised seven OpenVSX extensions with 35,800 downloads before anyone noticed. Your code review can't catch what your eyes can't render.

Where this actually came from

I didn't sit down one day and decide to write a book. I've been doing dev and devops on React Native projects for years, and somewhere in there I'd built up the unglamorous kind of knowledge nobody publishes: a warning to a teammate not to pod install blind on an unfamiliar repo, a note-to-self that build.gradle executes on sync, a half-remembered incident writeup I could never find again when I actually needed it. It was real, hard-won, and scattered across Teams/Slack, sticky notes, half-organized MD files, and my own memory.

So I sat down with Claude and turned the pile into something structured.

This is not finished, and I don't want it to be a solo project

The React Native Developer's Security Guide is 33 chapters on this threat model so far. Every attack in it is real, dated and sourced. Its companion, an opengrep rule set, turns every "here's the command to catch this" into something you can point at a repo or wire into CI. A finding is a reason to look, not a verdict.

Both are actively moving. Let's make this the place where scattered React Native developer-security knowledge gets consolidated. If you've hit one of these attacks, know a technique that's missing, or can tighten a rule in the companion set, please Open an issue, create a PR.

Your app was never the whole attack surface. Go find out where your React Native stack's weak points are, before somebody else does.

DEV Community: Stephan W.

The React Native Developer's Security Guide

Your MacBook is not a walled garden for your own repo

Where this actually came from

This is not finished, and I don't want it to be a solo project