Background location usage is justified and minimized
Why it matters
Background location is the single most scrutinised permission on both iOS and Android. Apple manually reviews every app that requests 'Always' location access, and Google Play requires a separate background location declaration form plus a valid use-case explanation. Under GDPR Art.5(1)(c), collecting precise background location when coarse foreground location would suffice violates the data-minimisation principle (CWE-359). CCPA §1798.100 treats geolocation as sensitive personal information requiring explicit disclosure. Apps that silently collect location in background services or push notification handlers — without user-visible features justifying it — face rejection, removal, and regulatory exposure.
Severity rationale
Medium because background location without justification triggers manual review on both platforms and violates GDPR data-minimisation, but exploitation requires a device already running the app.
Remediation
If background location is not genuinely needed, downgrade from 'Always' to 'When in Use' in Info.plist and remove ACCESS_BACKGROUND_LOCATION from AndroidManifest.xml. If background location is required, write a specific usage description that names the feature:
<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>Your location is used in the background to send alerts when you arrive at or leave saved places.</string>
For Android, submit the background location declaration form in Play Console (App content → Sensitive app permissions). Remove the permission from the manifest if the feature does not exist — its presence alone triggers scrutiny.
Detection
-
ID:
location-usage-justification -
Severity:
medium -
What to look for: Count all relevant instances and enumerate each. Check for background location permission requests:
ACCESS_BACKGROUND_LOCATIONinAndroidManifest.xml;NSLocationAlwaysAndWhenInUseUsageDescriptioninInfo.plistorapp.json;requestAlwaysAuthorization()in Swift;requestBackgroundPermissionsAsync()in Expo. If background location is requested, verify: (a) the usage description string specifically explains the background use case (not just "We need your location"); (b) there is a clear, demonstrable feature in the app that requires background location (delivery tracking, geofencing, workout tracking — not just "to improve recommendations"); (c) on Android, background location requires a separate permission dialog and Google Play requires a declaration form for apps using it. For foreground location, check that the app uses the most permissive-but-minimal permission level: usesACCESS_COARSE_LOCATIONwhere precise location is not needed, uses "When in Use" not "Always" for iOS where background is not needed. Also look for silent location collection patterns: location access in background services or push notification handlers that don't surface to the user. -
Pass criteria: Location permission level matches actual use case. At least 1 implementation must be verified. Background location is only requested when the app has a clear, demonstrable need. Usage description strings are specific and mention the feature requiring location.
-
Fail criteria: Background location requested without a clear feature need; usage description is generic ("We need your location for a better experience"); coarse location replaced with precise location unnecessarily; location accessed in background without declaration.
-
Skip (N/A) when: App uses no location features (no location APIs detected in source or manifest).
-
Detail on fail:
"NSLocationAlwaysAndWhenInUseUsageDescription is set but no background location feature is visible in the app — this will trigger manual review"or"ACCESS_BACKGROUND_LOCATION declared in AndroidManifest.xml but no geofencing or delivery-tracking feature found — Google will likely reject this without a valid explanation" -
Remediation: Background location is one of the most scrutinized permissions on both platforms. Apple rejects apps that request "Always" location without a clear user-facing reason.
- Downgrade from "Always" to "When in Use" if background location is not genuinely needed
- If background location IS needed, write a specific usage description:
- Bad: "We need your location"
- Good: "Your location is used in the background to send you alerts when you arrive at or leave saved places"
- For Android, submit the background location declaration form in Play Console (App content → Sensitive app permissions)
- Remove
ACCESS_BACKGROUND_LOCATIONfrom the manifest if background location is not used — it triggers automatic scrutiny
Review the configuration in
src/orapp/directory for implementation patterns. -
Cross-reference: For related patterns and deeper analysis, see the corresponding checks in other AuditBuffet audits covering this domain.
External references
- cwe · CWE-359 — Exposure of Private Personal Information to an Unauthorized Actor
- gdpr · Art.5(1)(c) — Data minimisation
- gdpr · Art.5(1)(b) — Purpose limitation
- ccpa · §1798.100 — Right to know about personal information collected
Taxons
History
- 2026-04-18·v1.0.0·Initial import from app-store-privacy-data·automated