OWASP Top 10 For Flutter – M4: Insufficient Input/Output Validation in Flutter

PreviousIntroduction NextOWASP Top 10 For Flutter – M3: Insecure Authentication and Authorization in Flutter

Last updated 3 days ago

Was this helpful?

OWASP Top 10 For Flutter – M4: Insufficient Input/Output Validation in Flutter

Welcome back to our deep dive into the OWASP Mobile Top 10, explicitly tailored for Flutter developers. In our last article, we tackled , exploring how lapses in identity and permissions checks can lead to serious breaches.

Today, we shift gears to M4: Insufficient Input/Output Validation, arguably one of the most pervasive and deceptively simple risks in any application. Last year, a popular finance app accidentally let users paste SQL payloads into its search bar, wiping out months of user data overnight. That’s the exact kind of risk M4 warns us about.

Even the most bulletproof authentication logic can be undone instantly if your app blindly trusts data crossing its boundaries. In a typical Flutter project, you’re juggling form inputs, HTTP APIs, deep links, platform channels, and WebViews, each a potential entry point for malformed or malicious data.

Over the following sections, we’ll define what OWASP means by “Insufficient Input/Output Validation,” and arm you with practical Dart and Flutter examples to lock down every trust boundary. Let’s dive in!

Understanding M4: Insufficient Input/Output Validation

Input Validation: Checking every piece of incoming data (user input, API responses, deep links, messages from native code) to ensure it matches the exact shape and constraints you expect.
Output Sanitization: Cleaning or encoding data before it leaves your app (when you render it in the UI, send it back to a server, or hand it over to native code), so no hidden threats slip through.

Think of input validation as inspecting every carriage entering the fortress, no weapons, no stowaways. Output sanitization is like searching messengers before they depart, ensuring they carry no secret orders for sabotage.

Common trust boundaries in a Flutter app include:

Forms and TextFields where users type data
HTTP requests and responses from your backend
Deep links or app links that jump into specific screens
Platform channels bridging Dart and native code
WebViews or HTML renderers showing rich content

Our goal in the following sections is to ensure that both checkpoints, validation, and sanitization are rock-solid so that malicious data can neither reach the heart of your app nor escape it.

How Validation Flaws Manifest in a Flutter or Dart App

This section explores four common patterns of M4 failures, explains why they’re dangerous, and provides clear examples of how to fix them. While many examples focus on the Flutter frontend, the principles apply equally to Dart-based backends. Once you understand the underlying issues and solutions, use them wherever needed in your Flutter and Dart codebases.

1. Insufficient Input Validation

Every time your app accepts free‑form data, from a search box to a deep link, it’s like inspecting every carriage at your fortress gate: "Every carriage must be searched for hidden weapons". Attackers can turn that innocent-looking bundle into a weapon if you let any unchecked item slip through.

A. SQL Injection in Local Databases

Imagine a simple search field wired straight into your SQLite database:

// BAD: trusts user input directly in SQL
Future<List<Map<String, dynamic>>> findUsers(String name) async {
  return await db.rawQuery(
    "SELECT * FROM users WHERE name = '$name'"
  );
}

An attacker typing:

Robert'); DROP TABLE users;--q

won’t see search results; they’ll crash your app and delete your users table. Local stores often hold sensitive profiles, tokens, or settings so that a single flawed query can expose or wipe everything.

A safer approach is to parameterize the query and allow‑list any dynamic parts:

const allowedCols = ['name', 'email'];
if (!allowedCols.contains(sortColumn)) {
  throw Exception('Invalid sort column');
}

final rows = await db.rawQuery(
  'SELECT * FROM users WHERE name = ? ORDER BY $sortColumn DESC',
  [name]
);

Here, the ? placeholder keeps the user’s input separate from SQL code, and we verify sortColumn against a known list instead of concatenating it blindly.

B. Command Injection via Platform Channels

When Dart invokes native scripts, the stakes are just as high. Suppose you do:

// BAD: hands raw user input to native exec
await platform.invokeMethod('runScript', {'path': userInputPath});

If the native side executes:

Runtime.getRuntime().exec("sh " + path);

then an input like:

/tmp/myscript.sh; rm -rf /

could run arbitrary shell commands. Treat the Dart–native boundary like another untrusted gate: check the path’s pattern before you send it:

final path = userInputPath;
if (!RegExp(r'^[\w\/\-]+\.sh\$').hasMatch(path)) {
  throw Exception('Invalid script path');
}
await platform.invokeMethod('runScript', {'path': path});

And remember: always repeat similar validation in your native code too—never let Dart’s checks be the only line of defense.

C. Deep‑Link Parameter Poisoning

Deep links let you jump straight to a payment screen or a product detail page, but they also open a backdoor if you trust their parameters blindly:

// BAD: assumes valid numbers and names
final amount = double.parse(uri.queryParameters['amount']!);
processPayment(amount, uri.queryParameters['to']);

An attacker could send:

myapp://pay?amount=0;DELETE%20FROM%20payments&to=Evil

or a non‑numeric string, crashing your parser or injecting malicious data.A safer flow is to parse, validate, and then sanitize:

final amtParam = uri.queryParameters['amount'] ?? '';
final amount = double.tryParse(amtParam);
if (amount == null || amount <= 0 || amount > 1e6) {
  return showError('Invalid payment amount');
}

final to = uri.queryParameters['to'] ?? '';
if (!RegExp(r'^[A-Za-z0-9_ ]{1,32}\$').hasMatch(to)) {
  return showError('Invalid recipient');
}

processPayment(amount, to);

You can even write integration tests or run a MITM proxy (like Charles) to feed malformed links and ensure your app rejects them cleanly.

D. Syntactic vs. Semantic Validation

It’s not enough to check format (“can this parse?”); you must also check the meaning (“does it make sense?”). For example, validating date ranges:

DateTime parseDate(String s) {
  try {
    return DateTime.parse(s);
  } catch (_) {
    throw FormatException('Use YYYY-MM-DD format');
  }
}

void validateDateRange(String start, String end) {
  final s = parseDate(start);
  final e = parseDate(end);
  if (s.isAfter(e)) {
    throw Exception('Start date must come before end date');
  }
}

Here, parsing ensures you won’t crash on invalid text; comparing dates enforces your business rule.

E. Unicode Normalization & Safe Character Sets

Free‑form text can include emojis, accents, and look‑alike characters. Normalize it so that “é” is always one code point, then allow only expected character classes:

import 'package:characters/characters.dart';

String normalize(String input) => input.characters.toString();

bool isValidComment(String input) {
  final text = normalize(input);
  final safe = RegExp(r"^[\p{L}\p{N}\s\.,!?'\-]+\$", unicode: true);
  return safe.hasMatch(text);
}

This prevents hidden control codes or bypasses that sneak past naive filters.

F. Avoiding Regex Denial‑of‑Service

Complex regex patterns with nested quantifiers can lock up your UI if an attacker feeds crafted input. Always anchor and simplify:

// BAD: catastrophic backtracking
final badRegex = RegExp(r"^(a+)+\$");

// GOOD: explicit length, no nested quantifiers
final safeRegex = RegExp(r"^[A-Za-z0-9]{1,32}\$");

Test any new regex against long, repetitive strings in a small Dart script to confirm it completes in milliseconds.

G. Client‑Side File Upload Validation

If your app lets users pick images or documents, don’t send them straight to the server:

Extension allow‑list: .jpg, .png, .pdf
Size limit: e.g., 5 MB
Content sniffing: verify it really is an image or PDF
Rename to a safe, server‑controlled filename

import 'dart:io';
import 'package:path/path.dart' as p;
import 'package:image/image.dart' as img;

Future<File> prepareUpload(File file) async {
  final ext = p.extension(file.path).toLowerCase();
  if (!['.jpg', '.png'].contains(ext)) {
    throw Exception('Only JPG/PNG images allowed');
  }
  if (await file.length() > 5 * 1024 * 1024) {
    throw Exception('Image must be under 5 MB');
  }
  final bytes = await file.readAsBytes();
  if (img.decodeImage(bytes) == null) {
    throw Exception('File is not a valid image');
  }
  final safeName = '${DateTime.now().millisecondsSinceEpoch}$ext';
  return file.copy(p.join(p.dirname(file.path), safeName));
}

H. Canonicalize Before You Validate

Attackers often use percent‑encoding or Unicode variants to slip past allow‑lists. Always decode into one canonical form, then apply your checks:

// Suppose you get a percent‑encoded name
final rawName = uri.queryParameters['user'] ?? '';
// 1. Decode percent‑encoding
final decodedName = Uri.decodeComponent(rawName);
// 2. Normalize Unicode
final normalized = decodedName.characters.toString();

// 3. Apply your allow‑list
final namePattern = RegExp(r'^[A-Za-z0-9_ ]{1,32}\$');
if (!namePattern.hasMatch(normalized)) {
  return showError('Invalid user name');
}

%2e%2e vs ..: Without decoding, RegExp(r'^[\w\-]+\$') might miss a path‑traversal attack.
Mixed‑width Unicode characters can hide dangerous sequences if you validate on raw code units.

Making canonicalization the first step of every validation routine ensures your regex and length checks see the actual data, not a cleverly encoded variant.

I. NoSQL / GraphQL Injection

While SQL injection is well‑known, modern apps often talk to NoSQL stores or GraphQL endpoints. Unvalidated inputs in query objects or GraphQL queries can let attackers manipulate filters or execute unauthorized queries.

// BAD: builds a Firestore query from untrusted map
final filter = jsonDecode(userJson);
final snapshot = await FirebaseFirestore.instance
    .collection('orders')
    .where(filter['field'], isEqualTo: filter['value'])
    .get();

To fix it, allow‑list field names and validate types before constructing queries:

const allowedFields = ['status', 'customerId'];
final field = filter['field'];
if (!allowedFields.contains(field)) {
  throw Exception('Invalid query field');
}
final value = filter['value'];
// ensure the right type, e.g. String or int
if (value is! String && value is! int) {
  throw Exception('Invalid query value type');
}
final snapshot = await FirebaseFirestore.instance
    .collection('orders')
    .where(field, isEqualTo: value)
    .get();

Beyond filter injections, be cautious when dynamically building Firestore document paths based on user input. If you let users control path segments like userId, projectName, or orderId without validation, they might access or overwrite data that doesn't belong to them, especially if your Firestore rules are too broad.

// BAD: user controls Firestore path
final doc = FirebaseFirestore.instance.doc('projects/$inputProjectId');

An attacker could craft inputProjectId as ../../admins/root, possibly navigating out of bounds or triggering unexpected rules behavior. The fix is to validate all Firestore path components explicitly.

final id = inputProjectId;
if (!RegExp(r'^[a-zA-Z0-9_-]{1,28}$').hasMatch(id)) {
  throw Exception('Invalid project ID');
}

Avoid path control characters like / or . unless absolutely necessary. Firestore treats document and collection paths as part of its access control model, so a poorly validated string can become a security bug.

J. JSON Schema Validation

While you can create your own JSON validator, using a package might work for you too. For complex payloads, embed a JSON Schema validator to enforce structure:

import 'package:json_schema/json_schema.dart';

final schema = await JsonSchema.createSchema({
  'type': 'object',
  'properties': {
    'userId': {'type': 'string'},
    'age': {'type': 'integer', 'minimum': 0},
  },
  'required': ['userId', 'age'],
});

void handlePayload(Map<String, dynamic> data) {
  final errors = schema.validateWithErrors(data);
  if (errors.isNotEmpty) {
    throw Exception('Payload validation failed: \$errors');
  }
  // proceed safely
}

2. Insufficient Output Sanitization

Even if input is clean, output can become dangerous when sent to contexts that interpret it, particularly HTML, CSV, or logging systems.

A. XSS in WebView

Loading unfiltered HTML is a direct path to script execution:

// BAD: runs all `<script>` tags in userHtml
_webViewController.loadHtmlString(userHtml);

Instead:

Sanitize HTML before loading:

// Use a sanitization library like html_unescape or sanitize_html
// import 'package:html/parser.dart' as html;

final cleanHtml = sanitizeHtml(userHtml);

Disable JavaScript if possible:

_webViewController
  .setJavaScriptMode(JavaScriptMode.disabled)
  .loadHtmlString(cleanHtml);

Whitelist tags and attributes if JS is needed.

B. CSV Injection

If you export user data into a CSV, spreadsheet apps may treat cells starting with = or - as formulas:

name, comment
Alice,=cmd|' /C calc'!A0

To prevent this, prefix dangerous cells with a single quote:

String escapeCsv(String field) {
  if (field.startsWith('=') || field.startsWith('+') ||
      field.startsWith('-') || field.startsWith('@')) {
    return "'\$field";
  }
  return field;
}

C. Unsafe URL Generation

When building query URLs:

// BAD: manual concatenation
final url = 'https://api.example.com/search?query=' + userInput;

Always use Dart’s Uri helpers:

final uri = Uri.https(
  'api.example.com',
  '/search',
  {'query': userInput},    // automatically percent‑encoded
);

With unsafe outputs now neutralized, let’s turn next to how context shapes what “safe” really means.

3. Lack of Contextual Validation

A string that’s safe in one scenario might be fatal in another. Context is king.

A. File Path Traversal

// BAD: naive path construction
final path = "\${appDir.path}/\$fileName";
File(path).readAsString();

If fileName is ../../etc/passwd, you could read system files (on rooted devices).A safe pattern:

import 'package:path/path.dart' as p;

final safeName = p.basename(fileName);
if (!safeName.endsWith('.txt')) {
  throw Exception('Only .txt files allowed');
}
final safePath = p.join(appDir.path, safeName);
File(safePath).readAsString();

B. Dynamic UI Generation

If you let the server send widget definitions as JSON, a malformed request could crash your app or introduce logic flaws. Always validate the JSON schema before mapping it to widget code. Check "JSON Schema Validation" section to learn more how you can do that.

C. Accessibility & Localization

Don’t forget to validate user inputs for different locales (dates, numbers) and ensure error messages and validation cues are announced via Flutter’s accessibility widgets (e.g., `Semantics`, `SnackBar`) so all users get clear, localized feedback.Here is an example for inspiration.

import 'package:flutter/material.dart';
import 'package:intl/intl.dart';

class LocalizedForm extends StatefulWidget {
  @override
  _LocalizedFormState createState() => _LocalizedFormState();
}

class _LocalizedFormState extends State<LocalizedForm> {
  final _formKey = GlobalKey<FormState>();
  DateTime? _pickedDate;

  @override
  Widget build(BuildContext context) {
    // Choose a locale, e.g. Norwegian
    final dateFormatter = DateFormat.yMMMMd(
      Localizations.localeOf(context).toString(),
    );

    return Form(
      key: _formKey,
      child: Column(
        children: [
          // Date input with locale‑specific parsing
          TextFormField(
            decoration: InputDecoration(
              labelText: 'Dato (${dateFormatter.locale})',
            ),
            keyboardType: TextInputType.datetime,
            validator: (value) {
              if (value == null || value.isEmpty) {
                return 'Please add a date'; // localized error
              }
              try {
                _pickedDate = dateFormatter.parseStrict(value);
              } catch (_) {
                return 'Bad datoformat'; // localized error
              }
              print('_pickedDate $_pickedDate');
              return null;
            },
          ),

          SizedBox(height: 20),

          ElevatedButton(
            onPressed: () {
              if (_formKey.currentState!.validate()) {
                // Announce success via accessibility
                ScaffoldMessenger.of(context).showSnackBar(
                  SnackBar(
                    content: Semantics(
                      label: 'Send',
                      child: Text('Send'),
                      liveRegion: true,
                    ),
                  ),
                );
              }
            },
            child: Text('Send'),
          ),
        ],
      ),
    );
  }
}

4. Failure to Validate Data Integrity

Even well‑formed and properly encoded data can be altered once stored or cached. You must verify it hasn’t been tampered with.

A. SharedPreferences Flag Tampering

import 'package:crypto/crypto.dart';
import 'dart:convert';

String computeHmac(String value) {
  final key = utf8.encode('APP_SECRET_KEY');
  return Hmac(sha256, key).convert(utf8.encode(value)).toString();
}

// Saving:
prefs.setString('isAdmin', 'false');
prefs.setString('isAdmin_hmac', computeHmac('false'));

// Reading:
final val = prefs.getString('isAdmin')!;
final mac = prefs.getString('isAdmin_hmac')!;
if (computeHmac(val) != mac) {
  // graceful fallback instead of crash
  print('⚠️ Data integrity check failed, reverting to secure default');
  return false;
}

B. Verifying Remote Config or Assets

If you download a JSON config or an asset at runtime (for feature toggles, theming, etc.), use a signature or checksum provided by your server. After download:

Compute the SHA‑256 of the payload.
Compare it against the checksum you received over a secure channel.

If they don’t match, reject the payload and fall back to defaults.Now that we’ve secured every gate for inputs, outputs, and stored data, it’s time to adapt these defenses to platform‑specific rules.

Platform‑Specific Nuances

Even though Flutter gives us a single codebase, Android and iOS (and Windows, Web, macOS, and Linux) enforce different rules under the hood. Your validation strategy must account for those differences.

1. File System & Sandbox

iOS: Apps live in a strict sandbox. Even if you allow ../ in a filename, iOS will block access outside your container.
Android: Modern Android uses scoped storage, but if you request legacy or external‑storage permissions, a path‑traversal attack can hit shared directories.

To mitigate:

Always use path_provider to get the correct app directory.
Normalize and strip directory parts with path.basename().
Target-scoped storage on Android and avoid broad storage permissions unless absolutely necessary.

2. Intents & URL Schemes

Flutter plugins like uni_links or receive_sharing_intent let you handle incoming data:

// Example using uni_links
void _handleIncomingLink(Uri uri) {
  // OS guarantees correct scheme, but query params remain untrusted
  final action = uri.queryParameters['action'] ?? '';
  if (!['view', 'edit', 'share'].contains(action)) {
    return _showError('Unknown action');
  }
  // Process only after validating every parameter
}

Tip: On Android, set android:autoVerify="true" in your AndroidManifest.xml to reduce phishing via fake intents, but Dart-side validation remains essential.

3. WebView Differences

Android WebView (Chromium-based) lets you disable file access and set Safe Browsing flags, but enabling JavaScript will run any script in loaded HTML.
iOS WKWebView respects Content Security Policies if you inject them, but will execute JavaScript if enabled.

Secure WebView setup for both platforms:

_webViewController
  .setJavaScriptMode(JavaScriptMode.disabled) // Turn off JS if possible
  .setBackgroundColor(const Color(0x00000000))
  .loadRequest(Uri.parse('https://trusted.domain'));

If you must enable JavaScript (e.g., for interactive widgets):

Sanitize the HTML.
Restrict JS bridges (JavaScriptChannel on Android, message handlers on iOS) to known methods.
Clear cache and data on logout to remove leftover scripts or cookies.

4. Native Code & MethodChannels

Platform channels let Dart talk to Kotlin/Java or Swift/Objective-C, another trust boundary that needs validation on both sides.

// Dart side (GOOD)
final result = await platform.invokeMethod('getConfig', {'key': configKey});
if (result is! String || result.length > 256) {
  throw Exception('Invalid config from native');
}

On the Kotlin side:

// Android native (Kotlin)
MethodChannel(flutterEngine.dartExecutor.binaryMessenger, "app/config")
  .setMethodCallHandler { call, res ->
    val key = call.argument<String>("key") ?: run {
      res.error("BAD_KEY", "Missing config key", null)
      return@setMethodCallHandler
    }
    if (key.isEmpty() || key.length > 64) {
      res.error("BAD_KEY", "Invalid config key", null)
      return@setMethodCallHandler
    }
    res.success(loadConfig(key))
  }

Use Pigeon to auto‑generate type-safe stubs and eliminate a whole class of runtime type errors.

By understanding sandbox models, intent handling, WebView quirks, and native bridges, you can tailor your validation strategy to close every gap.

Completing OWASP’s Prevention Checklist

OWASP’s “How Do I Prevent M4?” is built on these six pillars. So far, we’ve examined Input Validation, Output Sanitization, Context‑Specific Validation, and Data Integrity. Two more critical pieces remain: Secure Coding Practices and Continuous Security Testing & Maintenance.

1. Secure Coding Practices

Unsafe APIs can undo even rock-solid validation. Elevate your code quality by relying on high‑level, type‑safe libraries and avoiding string concatenation for any data that reaches a lower layer.

A. Parameterized Queries & ORMs

Rather than hand‑crafting SQL strings, use an ORM like Drift (formerly Moor). Drift auto‑parameterizes queries and provides Dart types with compile‑time checks:

// Define your Users table
class Users extends Table {
  IntColumn get id     => integer().autoIncrement()();
  TextColumn get name  => text()();
  TextColumn get email => text()();
}

// In your database class:
Future<List<User>> findUsersByName(String name) {
  // Drift ensures 'name' is a parameter, not part of the SQL code
  return (select(users)..where((u) => u.name.equals(name))).get();
}

With this approach, SQL injection is impossible, and your data layer is much easier to maintain.

B. Safe URL & Path Construction

Building URIs or file paths by hand invites subtle bugs and vulnerabilities. Always use Flutter’s built‑in helpers:

// Safe HTTP URL
final uri = Uri.https(
  'api.example.com',
  '/search',
  {'query': userInput}, // automatically percent‑encoded
);

// Safe file path
import 'package:path/path.dart' as p;
final safeName = p.basename(userInputFilename);
final file = File(p.join(appDir.path, safeName));

Uri and the path package handle encoding and normalization, so you never accidentally slip unsafe characters into a URL or path.

2. Continuous Security Testing & Maintenance

Validation logic isn’t “set and forget.” You must ensure your defenses stay aligned as your app evolves—new fields, screens, and data flows. Here’s how to bake security checks into your workflow:

A. Fuzzing with Unit & Integration Tests

Write tests that feed known attack patterns into your validation and data‑handling code:

// test/security_fuzz_test.dart
import 'package:flutter_test/flutter_test.dart';
import 'package:my_app/database.dart';

void main() {
  final db = MyDatabase();
  final payloads = [
    "Robert'); DROP TABLE users;--",
    "<script>alert(1)</script>",
    "../etc/passwd"
  ];

  for (var p in payloads) {
    test('findUsersByName rejects `$p`', () async {
      expect(
        () => db.findUsersByName(p),
        throwsA(isA<Exception>()),
      );
    });
  }
}

Extend these to widget tests, use WidgetTester or an external proxy to inject malformed deep links or simulate malicious user input.

B. Static Analysis & CI Integration

Automate linting and test runs so vulnerabilities never slip past a pull request:

# .github/workflows/flutter.yml
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: subosito/flutter-action@v2
        with:
          channel: stable
      - run: flutter pub get
      - run: flutter analyze --fatal-infos
      - run: flutter test --coverage

Add security‑focused lints (e.g., flagging rawQuery usage or unrestricted JavaScriptMode.unrestricted) to catch risky code patterns before review.

If you're using Firebase Cloud Functions as your backend, don’t rely on client-side validation alone. Functions receive raw data directly from users, and even though the UI might enforce types and formats, an attacker can bypass the frontend and call the function directly using tools like Postman or a custom app.

// BAD: Accepts user-supplied amount blindly
exports.processPayment = functions.https.onCall((data, context) => {
  const amount = data.amount;
  // processes payment...
});

This opens the door to abuse if the amount is not a number, or it's negative, or too large.Always validate critical fields on the backend, even if they've already been checked on the client:

if (typeof data.amount !== 'number' || data.amount <= 0 || data.amount > 100000) {
  throw new functions.https.HttpsError('invalid-argument', 'Invalid amount');
}

Whether it’s a Cloud Function or a Firestore path, your server-side Firebase logic should replicate the same rigorous checks as your Flutter app.

C. Validation Coverage & Maintenance

As OWASP warns under “Improper Data Validation,” adding a new form field and forgetting its validator is easy. Prevent that drift by centralizing and testing your validators:

// validators.dart
final Map<String, FormFieldValidator> validators = {
  'email': emailValidator,
  'password': passwordValidator,
  'phone': phoneValidator,
  // …when you add 'address', add addressValidator here
};

Then verify coverage with a unit test:

// test/validator_coverage_test.dart
import 'package:flutter_test/flutter_test.dart';
import 'package:my_app/validators.dart';

void main() {
  test('All form fields have validators', () {
    final formFields = ['email', 'password', 'phone'];
    expect(
      validators.keys.toSet(),
      equals(formFields.toSet()),
      reason: 'Form fields and validators must stay in sync',
    );
  });
}

And never skip calling _formKey.currentState!.validate() on submit—otherwise, none of your carefully written validators will run.

Quick Checklist

Before we end this article, I made a quick checklists for you to ensure you are on top of the security for your application to comply the M4 best practices.[ ] All user inputs run through allow‑lists and type checks[ ] Outputs to HTML/CSV/URLs are sanitized/escaped[ ] Percent‑encoding & Unicode are canonicalized before validation[ ] NoSQL/GraphQL filters validated against field‑name allow‑lists[ ] Integrity of persisted/cached data verified (HMAC/checksum)[ ] CI runs both static (lint/SAST) and dynamic (fuzz/DAST) tests[ ] Firestore paths are validated and encoded before use[ ] Firebase Cloud Functions enforce server-side schema validation

Conclusion

Remember that finance app wiped out by a single SQL payload? By layering strict input checks, context‑aware rules, and continuous testing, you build a fortress where no malicious data can slip in or out. Until then, keep validating like a fortress guard, no unchecked carriage should pass!Stay tuned for our next article on M5: Insecure Communication.

PreviousIntroduction NextOWASP Top 10 For Flutter – M3: Insecure Authentication and Authorization in Flutter

Last updated 3 days ago

Was this helpful?