react-native-fs is the long-standing library for native filesystem access in React Native, and the two things that matter for security are its maintenance status and how carefully your own code constructs the file paths you pass to it. If you have react-native-fs in your package.json, you have granted your app direct read and write access to the device filesystem, which is exactly the capability an attacker wants to abuse. The library gives you the power; whether it becomes a liability depends on the version you depend on and the paths you feed it.
This is a practical review of react native fs: where it stands today, what to watch for, and how to use device file access without opening a hole.
What react-native-fs does
The package exposes native modules on iOS and Android that let JavaScript read, write, move, and delete files, plus download and upload to and from the device. That is genuinely useful for caching, offline data, document handling, and media, and it is why the library has been a default choice for years with weekly download counts well into the hundreds of thousands.
It is also a broad capability. Filesystem access is one of the higher-privilege things a mobile app can do, so the library sits squarely in your app's trusted computing base. A bug in how you call it, or in the library itself, has more consequence than a bug in a UI helper.
The maintenance question you should ask first
Before anything else, check whether the copy you depend on is actively maintained. The original itinance/react-native-fs repository has seen little recent release activity and is widely described as inactive, with the maintainers themselves having discussed the project's future. On a platform that moves as fast as React Native, an unmaintained native module is a growing liability, because it may not keep pace with the New Architecture, and if a security issue surfaces there may be nobody to ship a fix.
The community responded with maintained forks. @dr.pogodin/react-native-fs refactored the codebase toward the modern create-react-native-library setup and New Architecture compatibility while keeping backward compatibility, and @exodus/react-native-fs is another actively maintained alternative. If you are starting fresh, evaluating a maintained fork is usually the better bet than pulling in a package whose upstream has stalled.
# Check what you actually depend on and when it was last updated
npm ls react-native-fs
npm view react-native-fs time.modified
Path handling is where the real risk lives
The most common security bug in code that uses react-native-fs is not in the library, it is in the caller building a path from untrusted input. If a filename or path segment comes from a server response, a deep link, a downloaded manifest, or user input, treating it as trusted invites path traversal.
Consider a download handler that names the local file after a server-provided string. A value like ../../some/other/app/file can escape the directory you intended and read or clobber files elsewhere in your app's sandbox.
import RNFS from 'react-native-fs';
// RISKY: server controls the filename, so it controls the path
const dest = `${RNFS.DocumentDirectoryPath}/${serverProvidedName}`;
await RNFS.downloadFile({ fromUrl: url, toFile: dest }).promise;
The fix is to sanitize the component to a known-safe basename and confirm the resolved path stays inside the directory you own.
// SAFER: strip path separators, keep only a plain filename
const safeName = serverProvidedName.replace(/[^a-zA-Z0-9._-]/g, '_');
const dest = `${RNFS.DocumentDirectoryPath}/${safeName}`;
Never let external input contribute /, .., or absolute path prefixes to a filesystem operation. Allowlist the characters you accept rather than trying to blocklist the dangerous ones.
Downloads, TLS, and what you write to disk
Because react-native-fs can download directly to disk, two adjacent concerns come with it. Fetch only over HTTPS, and do not disable certificate validation to make a self-signed test server work, since that setting has a way of surviving into production. And be deliberate about what you persist: writing secrets, tokens, or personal data to a plain file in the documents directory leaves it readable to anything with filesystem access on a compromised or rooted device. Use the platform keystore or secure storage for anything sensitive, and reserve react-native-fs for genuinely file-shaped data.
Fitting it into your dependency hygiene
Treat react-native-fs like any high-privilege dependency. Pin it in your lockfile, commit the lockfile, and review its diff in pull requests so a surprise transitive update does not slip in. Run npm audit in CI, and because native modules can lag on advisories, an SCA tool such as Safeguard helps by tracking whether the exact version you resolved has known issues rather than trusting that "latest" is safe. When you evaluate a fork, apply the same checks to it: recent releases, an active issue tracker, and a maintainer who responds. Our security academy covers this evaluation process in more depth.
FAQ
Is react-native-fs safe to use?
The library itself is a widely used, capable filesystem module, but the original package has limited recent maintenance, and most real risk comes from how you build the file paths you pass to it. Prefer an actively maintained fork and sanitize any path derived from external input.
Is react-native-fs still maintained?
The original itinance/react-native-fs has seen little recent release activity and is commonly considered inactive. Maintained forks such as @dr.pogodin/react-native-fs and @exodus/react-native-fs carry the project forward with New Architecture support.
How do I prevent path traversal with react-native-fs?
Never let untrusted input supply path separators or ... Reduce any external filename to a plain basename with an allowlist of safe characters, build the destination inside a directory you control, and confirm the resolved path stays within it.
Should I store sensitive data with react-native-fs?
No. Files written to the documents directory are readable to anything with filesystem access on a rooted or compromised device. Use the platform keystore or secure storage for tokens and personal data, and reserve react-native-fs for non-sensitive, file-shaped content.