Common Permission Escalation in Food Delivery Apps: Causes and Fixes

Permission escalation occurs when an app requests a dangerous permission (e.g., READ_PHONE_STATE, ACCESS_FINE_LOCATION, WRITE_EXTERNAL_STORAGE) that it does not actually need, then later grants itself

Permission Escalation in Food Delivery Apps

1. Technical Root Causes

Permission escalation occurs when an app requests a dangerous permission (e.g., READ_PHONE_STATE, ACCESS_FINE_LOCATION, WRITE_EXTERNAL_STORAGE) that it does not actually need, then later grants itself additional privileges through a mis‑configured manifest or runtime request flow. In food delivery apps the most common culprits are:

These technical oversights are amplified in food delivery apps because they rely heavily on real‑time location, camera, microphone, and phone state to deliver a seamless experience (e.g., tracking driver ETA, scanning QR codes for order pickup, auto‑filling payment details).

2. Real‑World Impact

A concrete example: a major food delivery platform rolled out a “track driver in real time” feature that required ACCESS_FINE_LOCATION and FOREGROUND_SERVICE. The manifest was updated once, but the app also requested READ_PHONE_STATE for “detect incoming calls while delivering”. Users reported the app silently making phone calls, leading to a 12 % drop in app store rating within a week and a subsequent patch that removed the unnecessary permission.

3. Manifestation Examples (5‑7)

1. Background location tracking without user consent – The app requests ACCESS_FINE_LOCATION for “find nearby restaurants”, then continues to receive location updates while the app is in the background, draining battery and raising privacy flags.
2. Camera permission used for QR scanning but also for taking photos of the delivered food – The same CAMERA permission is granted, allowing the app to capture images without explicit user intent.
3. SMS/Call permission for automatic OTP retrieval – The app adds READ_SMS and READ_PHONE_STATE to auto‑fill verification codes, but the permission also enables the app to read incoming calls, a clear escalation.
4. Microphone access for “voice order” feature that is never used – The app declares RECORD_AUDIO for a voice command module that was removed in a previous release, yet the permission remains.
5. Storage permission for caching menus that is later abused to read private files – WRITE_EXTERNAL_STORAGE is granted for saving temporary menu images; a malicious component later reads other app data from the same storage location.
6. Location + Bluetooth permission for indoor navigation – The app requests both ACCESS_FINE_LOCATION and BLUETOOTH_CONNECT to map restaurant interiors, but Bluetooth can be leveraged to track user movement across venues.
7. Accessibility service permission for “screen reader” – The app declares BIND_ACCESSIBILITY_SERVICE to support screen‑reader users, but the service can be abused to overlay UI elements, causing phishing‑style attacks.

4. Detection

Focus on permission‑to‑feature mapping: each requested permission should have a documented justification (e.g., “CAMERA – required for QR‑code scanning at pickup”). Any deviation is a red flag.

5. Fixes (Code‑Level Guidance)

1. Trim manifest – Remove any that is not required for a specific feature. Use feature‑specific permission groups (e.g., fineLocation only when GPS is needed).

   // Bad
   <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/>

   // Good – request only when GPS UI is visible
   if (hasLocationFeature()) {
       ActivityCompat.requestPermissions(this,
           new String[]{Manifest.permission.ACCESS_FINE_LOCATION}, REQUEST_LOCATION);
   }

1. Scope runtime requests – Request permissions just before they are needed, not at app start.

   // Instead of a blanket request in onCreate()
   if (needCameraForQr()) {
       requestCameraPermission();
   }

1. Check permission state each time – Do not rely on a one‑time grant; re‑check before using the permission.

   if (ContextCompat.checkSelfPermission(this, Manifest.permission.ACCESS_FINE_LOCATION)
           != PackageManager.PERMISSION_GRANTED) {
       // Prompt user again or disable location‑based features
   }

1. Isolate third‑party SDK permissions – Review each SDK’s manifest, and if a SDK adds unwanted permissions, either exclude the SDK or use a wrapper that strips them via android:extractNativeLibs="false" and custom Application class.

1. Graceful degradation – When a required permission is denied, disable the related feature rather than crashing.

   if (ContextCompat.checkSelfPermission(this, Manifest.permission.READ_SMS)
           != PackageManager.PERMISSION_GRANTED) {
       // Show fallback UI: manual OTP entry
   }

1. Use Android’s permission rationale – Provide a clear shouldShowRequestPermissionRationale message that ties the permission to the concrete user benefit (e.g., “We need location to show nearby restaurants and estimate delivery time”).

6. Prevention

• Feature‑first permission matrix – Create a spreadsheet linking each app feature to the minimal permission set. Enforce this matrix during design reviews.
• CI/CD gate – Add a pre‑merge step that runs a static analysis script (e.g., a Gradle task invoking android lint with a custom rule) to flag any permission not present in the matrix.
• Automated UI validation – Integrate SUSA or a similar autonomous QA tool to run a suite of flows (login → order → checkout) and assert that only expected permission prompts appear.
• **Regular