# Security Vulnerability Analysis – Purolator Delivery Pro (Mobile App) ## Executive Summary This review focuses on **low-severity and informational** findings in the Purolator Delivery Pro Android application that remain relevant even after APIM key rotation. The assessment was performed using: * Static analysis of the decompiled Flutter client (via Blutter) * Manual review of authentication flows, offline storage, and network calls * Limited traffic inspection Because this analysis is **client-only**, several items are presented as **risk scenarios / questions for backend confirmation**, not confirmed vulnerabilities. Most findings fall under **hardening / defense-in-depth**, not urgent issues. --- ## Findings Overview | # | Finding | Severity | | - | ---------------------------------------------------------------- | --------------------------------------- | | 1 | Firebase API key exposed but correctly restricted | Info | | 2 | Application Insights instrumentation key exposed | Low | | 3 | Client-side business logic checks (`isBlocked`, POD validation) | Low (→ Medium if backend trusts client) | | 4 | Local data storage (FlutterSecureStorage) – expected mobile risk | Info | | 5 | Potential client-side POD queue race condition | Info | | 6 | HERE OAuth usage + no pinning for some third-party APIs | Info | | 7 | Predictable secure storage key names | Info | | 8 | Session timeout / token lifetime unclear | Question | | 9 | Logging detail + no tamper/root detection | Info | --- ## 1. Firebase API Key – Exposed but Properly Restricted (Info) **Location:** `objs.txt` Example: ``` AIzaSyAE6x4E1lFTgAAy0TiBNSOXKtmYHIM0aTk ``` A test sign-up attempt returns: ``` "ADMIN_ONLY_OPERATION" ``` This indicates: * Anonymous sign-up is blocked * Firebase Security Rules are correctly applied * Exposing the API key in mobile apps is **expected per Firebase documentation** **Severity:** **Info** **Recommendations:** * Keep Firebase Security Rules strict * Consider enabling Firebase App Check * Rotate key on a normal schedule (not urgent) --- ## 2. Application Insights Instrumentation Key Exposure (Low) **Location:** `util/environments.dart` Example: ``` 2e942d35-2e18-4811-abc3-db288fb6e555 ``` The instrumentation key allows **unauthenticated write access** to telemetry. **Possible abuse if someone chooses to target it:** * Inject fake telemetry events * Pollute dashboards * Hide real alerts behind noise * Trigger fake application behavior in monitoring systems Example: ```bash curl -X POST https://dc.services.visualstudio.com/v2/track \ -H "Content-Type: application/json" \ -d '{ "name":"Microsoft.ApplicationInsights.Event", "iKey":"2e942d35-2e18-4811-abc3-db288fb6e555", "data":{"baseType":"EventData","baseData":{"name":"FakeEvent"}} }' ``` This does **not** provide read access or Azure control. **Severity:** **Low** **Recommendations:** * Monitor for anomalous telemetry * Consider using more restrictive ingestion methods if practical * Rotate the key if telemetry integrity is business-critical --- ## 3. Client-Side Business Logic & Blocked Driver Checks **Severity: Low → Medium (if backend trusts client)** ### What is seen in the client The sequence for login: 1. Driver completes phone number + OTP 2. App calls `/api/drivers/login` 3. Backend returns a `GlobalUser` including `isBlocked` 4. The **client** checks `isBlocked` **after** successful API response Example: ```dart if (globalUser.isBlocked == true) { return ErrorResult("This number is blocked..."); } ``` Similar patterns exist for POD form validation, address checks, barcode formatting, etc. ### Why severity is Low right now This report is client-only. If the backend **already validates**: * Blocked driver state * Status transitions * POD submissions (server-side rules) * Barcode/authenticity checks then the client checks are **just user-interface validation**, which is normal. ### When it becomes Medium If backend endpoints currently trust the client and do not re-validate these conditions, a modified client could bypass them. ### Backend confirmation questions 1. Does `/api/drivers/login` or auth middleware return **401/403** for blocked users? 2. Do POD/scan/status endpoints re-validate: * Driver permissions * Valid transitions * Package authenticity? **Recommendation:** Ensure all authorization and validation logic is **server-side**, with the client acting only as a presentation layer. --- ## 4. Local Data Storage – Expected Behavior (Info) **Location:** `util/secure_storage/secure_storage.dart` The app uses **FlutterSecureStorage**, which maps to Android Keystore + EncryptedSharedPreferences. This aligns with OWASP MASVS recommendations. **Risk:** Rooted/compromised devices could potentially extract stored encrypted data. This is an **inherent platform risk**, not an app flaw. **Severity:** **Info** **Recommendations:** * Optionally detect rooted/jailbroken devices * Clear sensitive data on logout * Use short-lived backend sessions to reduce token value --- ## 5. POD Batch Upload Queue – Potential Race Condition (Info) Client’s offline upload queue: * Stores POD actions locally * Sends them asynchronously * Removes them after upload From client-side view, there appears potential for duplicate requests if deletions or retries overlap. **Severity:** **Info** (client-side speculation only) **Backend recommendation:** * Ensure POD endpoints are **idempotent** * Implement deduplication on the server * Use unique request IDs if not already implemented --- ## 6. HERE OAuth Usage + No Pinning for Third-Party APIs (Info) ### Observed OAuth Token Request Example captured request: ``` POST /oauth2/token Authorization: OAuth oauth_consumer_key="tbhN9qHuFvA24UJjg--qgQ", ... {"grantType":"client_credentials"} ``` Example response (abbreviated): ```json { "accessToken": "", "expiresIn": 86399 } ``` * All communication is over HTTPS * This appears to be standard HERE SDK OAuth flow * The `consumer_key` is a public identifier; the shared secret never appears on wire ### Risk * Without certificate pinning, a strong attacker capable of TLS MITM could observe HERE token exchanges * This mostly impacts **HERE quota / address integrity**, not core Purolator systems * Many apps accept this risk for third-party APIs due to operational complexity **Severity:** **Info** **Recommendations:** * Continue pinning your own backend domains * Pinning third-party APIs optional; often avoided due to CDN/cert rotations * Optionally validate address outputs on the server --- ## 7. Predictable Secure Storage Keys (Info) Examples: ``` "userDetails" "userAgencyInfo" "savePackagePODImages" ``` If an attacker already has access to secure storage (rooted device), key names add minimal extra information. **Severity:** **Info** **Recommendation:** Change key names or hash them only if desired—pure hardening, low priority. --- ## 8. Session Timeout / Token Lifetime Unclear (Question) Not enough information in client code to determine: * Token lifetime * Refresh token strategy * Session revocation behavior * Whether blocked drivers lose active sessions immediately **Questions:** 1. What is the configured session timeout? 2. Are Firebase refresh tokens used, and can they be revoked rapidly? 3. Any device binding or session limits? (No severity assigned yet.) --- ## 9. Logging Detail & Missing Tamper/Root Detection (Info) Client code contains: * Verbose debugging logs * Internal function names * No visible APK tamper detection * No root/jailbreak detection * No Frida/Xposed/Debugger detection **Risk:** Not a vulnerability by itself but reduces resistance to reverse engineering. **Severity:** **Info** **Recommendations:** * Minimize debug logs in production * Optionally add: * APK signature validation * Basic tamper/root detection * Anti-debug heuristics --- ## Scope & Limitations * This is **client-side analysis only** * Backend behavior was not visible * Many findings depend on how the backend already validates and enforces security * If backend protections already exist, most items remain low/info