Securing Mobile App Configuration: A Case Study in XML Security Risks

Röya Məhərrəmli — Sat, 29 Aug 2026 10:26:42 +0000

Introduction

Mobile applications often rely on configuration files to store settings such as API endpoints, permissions, and security parameters. While convenient, these files can become a serious liability when sensitive data or weak security rules are embedded directly inside them. This post analyzes a sample XML configuration file for a mobile application, identifies the security risks it contains, and proposes concrete solutions — including a Dart program that validates the configuration before it is trusted by the app.

Risks

1. Hardcoded API Key

<apiKey>ABCD1234-EFGH5678-IJKL9101</apiKey>

The API key is stored in plain text directly inside the configuration file. Anyone who gains access to the file — through a leaked backup, a decompiled APK, or a misconfigured repository — obtains full access to the API on the app's behalf. Because the key never changes unless manually rotated, a single leak can compromise the app indefinitely.

2. Hardcoded Encryption Key

<key>Base64EncodedEncryptionKey==</key>

The encryption key protecting the app's data is stored unencrypted, right next to the data it's supposed to protect. This defeats the purpose of encryption entirely: if the key and the ciphertext are shipped together, anyone with file access can decrypt everything. Base64 encoding is not encryption — it's just a text representation and offers no security on its own.

3. Overly Permissive / Ambiguous Permissions

<permission name="storage" required="false" />
<permission name="camera" required="false" />

Marking permissions as required="false" does not restrict access — it leaves the decision loosely defined, with no role-based logic behind it. This violates the principle of least privilege: an app should request only the permissions it strictly needs, and access should be tied to what the user's role actually requires, not left as an optional flag with no governing policy.

4. Overly Broad Firewall Rule

<rule action="allow" ip="192.168.1.0/24" />
<rule action="deny" ip="0.0.0.0/0" />

The rule ordering itself is correct — firewalls typically apply the first matching rule, so a specific allow before a catch-all deny is standard practice. The real risk is the scope of the allow rule: /24 grants access to 256 individual addresses on the local network. If even one device on that subnet is compromised, it inherits trusted access. The fix is narrowing the range to only the specific hosts that genuinely need it.

Solutions

API key and encryption key: Neither should ever live inside a file shipped with the app. The most practical approach for small-to-medium projects is to keep a lightweight backend server as an intermediary: the app talks to your own server, and only that server holds the API key (as an environment variable, not in code). The mobile app itself never sees the key, so decompiling the APK reveals nothing useful. Larger organizations may formalize this further with a dedicated secrets manager, but the underlying principle is the same — secrets stay off the device.

Permissions: Replace the flat required flag with role-based access control (RBAC). Permissions should be evaluated dynamically based on the authenticated user's role, and the app should request each dangerous permission (camera, storage) only at the moment it's actually needed — not declare it as a vague optional default.

Firewall rules: Keep the existing allow-then-deny ordering, but narrow the allow rule to specific trusted IP addresses or a much smaller subnet instead of an entire /24 block. Rules should be reviewed periodically to confirm they still reflect the minimum access actually required.

Code

Below is a Dart program that parses the configuration file and validates it against four rules: the API key must not be empty, the timeout must fall between 10 and 60 seconds, all user IDs must be unique, and every firewall rule must use a valid allow or deny action.

import 'dart:io';
import 'package:xml/xml.dart';

class ValidationResult {
  final bool isValid;
  final List<String> errors;

  ValidationResult(this.isValid, this.errors);
}

ValidationResult validateConfig(XmlDocument document) {
  final errors = <String>[];

  // 1. apiKey must not be empty
  final apiKeyElement = document.findAllElements('apiKey').firstOrNull;
  final apiKey = apiKeyElement?.innerText.trim() ?? '';
  if (apiKey.isEmpty) {
    errors.add('apiKey is missing or empty.');
  }

  // 2. timeout must be between 10 and 60 seconds
  final timeoutElement = document.findAllElements('timeout').firstOrNull;
  final timeoutText = timeoutElement?.innerText.trim();
  final timeout = int.tryParse(timeoutText ?? '');
  if (timeout == null || timeout < 10 || timeout > 60) {
    errors.add('timeout must be a number between 10 and 60 seconds '
        '(found: ${timeoutText ?? "missing"}).');
  }

  // 3. all <user> elements must have unique id attributes
  final userElements = document.findAllElements('user');
  final seenIds = <String>{};
  for (final user in userElements) {
    final id = user.getAttribute('id');
    if (id == null) {
      errors.add('A <user> element is missing an id attribute.');
      continue;
    }
    if (seenIds.contains(id)) {
      errors.add('Duplicate user id found: $id');
    } else {
      seenIds.add(id);
    }
  }

  // 4. firewall rule actions must be "allow" or "deny"
  const validActions = {'allow', 'deny'};
  final ruleElements = document.findAllElements('rule');
  for (final rule in ruleElements) {
    final action = rule.getAttribute('action');
    if (action == null || !validActions.contains(action)) {
      errors.add('Invalid firewall rule action: '
          '${action ?? "missing"} (ip: ${rule.getAttribute('ip') ?? "unknown"})');
    }
  }

  return ValidationResult(errors.isEmpty, errors);
}

void main() {
  final file = File('config.xml');

  if (!file.existsSync()) {
    print('Error: config.xml not found.');
    exit(1);
  }

  final content = file.readAsStringSync();
  final document = XmlDocument.parse(content);

  final result = validateConfig(document);

  if (result.isValid) {
    print('Configuration is valid.');
  } else {
    print('Configuration validation failed:');
    for (final error in result.errors) {
      print(' - $error');
    }
    exit(1);
  }
}

How it works

findAllElements('apiKey') searches the whole document for that tag; .firstOrNull avoids a crash if it's missing entirely.
int.tryParse safely converts the timeout text to a number, returning null instead of throwing if the value is malformed — that null is treated as a failure.
A Set<String> (seenIds) is used to track user IDs because sets automatically reject duplicates, making the uniqueness check a single contains lookup per user.
Firewall actions are checked against a fixed set of valid values (allow, deny) rather than trusting whatever string appears in the file.

Conclusion

None of the four issues in this configuration file involve exotic attacks — they're the kind of small, easy-to-overlook mistakes that show up in real breaches: a hardcoded secret, a vague permission, an oversized network rule. Catching them requires no special tooling, just the habit of asking "what happens if this file leaks?" before shipping it. Combining that mindset with automated validation, like the Dart program above, turns a manual review into a repeatable safeguard that runs every time the configuration changes.

DEV Community: Röya Məhərrəmli