The React Native Developer's Security Guide

What it is

This is a book (current as of August 2026) whose scope is the near-inverse of what the catalog summary describes. It explicitly excludes app-hardening topics — secure storage, cert pinning, anti-tampering, MASVS — and instead treats the React Native developer's workstation, toolchain, repository, and CI as the asset under attack. The core thesis: an RN repo is "a polyglot execution environment disguised as a JavaScript project," and a single git clone && yarn && pod install && yarn ios runs attacker-controllable code in five runtimes before your app ever executes. It ships with a companion detection project, stephanww/rn-dev-security-guide-opengrep (119 opengrep rules across 20 YAML files, each keyed to the chapter explaining the attack it detects).

How it works

The threat model rests on developer machines holding a signed distribution channel to all users: npm publish token, GitHub PAT, iOS distribution certificate, Android upload keystore, App Store Connect key, .env staging creds, browser cookies, and increasingly an AI agent authorized to run shell commands. Owning that laptop for ten minutes beats compromising any single user's phone. Specific execution surfaces named: Ruby/CocoaPods, Xcode build phases and XCSSET, Gradle executing merely on opening a project, the committed gradle-wrapper.jar binary, and the RN dev server (CVE-2025-11953). Note the page's warning that opening the folder in your editor can be enough to trigger execution (Ch. 13) — you don't have to run install.

What to do

The book is organized by reader intent; the relevant entry points:

• Sent a repo you haven't opened: Appendix B — the safe-clone runbook — before you cd into the directory.
• Just cloned something sketchy: Appendix C (macOS triage one-liners) → Ch. 31 (incident response) → Ch. 25 (what happens after postinstall).
• Hardening a team: Appendix A (file risk atlas) → Ch. 28 (hardening installs) → Ch. 29 (isolation) → Ch. 32 (enforcement).
• Single most useful page: Appendix A, the file risk atlas — "just tell me which files to watch."

The opengrep rules can be pointed at a whole repo, wired into CI, or run as a pre-commit hook.

Caveats

The author stresses this field moves fast enough that undated advice is "actively harmful" — claims are dated and version-scoped, and content is fixed to August 2026. The opengrep README documents what the rules deliberately do not catch. Ch. 27 makes an operational point worth flagging: deleting a malicious package is not remediation, because persistence outlives the package.

flowchart TD
    A[Received a repo] --> B{Opened it yet?}
    B -->|No| C[Appendix B: safe-clone runbook]
    B -->|Yes / worried| D[Appendix C triage one-liners]
    D --> E[Ch.31 incident response]
    E --> F[Ch.27: deleting package ≠ remediation]
    G[Note: opening in editor alone<br/>can execute - Ch.13] -.-> B