Cyber Security

Why OWASP has a separate Top 10 for Mobile Apps?

1. Different Attack Surface

   • Mobile apps interact with device hardware (GPS, camera, sensors, Bluetooth, NFC) unlike web apps.

   • Risks like insecure data storage on device or improper use of platform permissions are unique to mobile.
     
     

2. Platform-Specific Security Models

   • iOS and Android have sandboxing, app store review, permission models—different from browsers/servers.
     
     

3. Offline Data & Local Storage

   • Mobile apps often store sensitive data (tokens, cached files) locally, increasing risk of reverse engineering and tampering.
     
     

4. Reverse Engineering & Tampering Risks

   • Mobile apps are distributed as binaries (APK, IPA) which attackers can decompile, modify, and repackage.
     
     

5. Network & API Dependencies

   • Mobile relies heavily on backend APIs + insecure communication channels (public Wi-Fi, mobile networks).
     
     

6. User Behavior

   • Users install apps from unofficial sources (especially on Android), increasing malware risks.

01- Improper Credential Usage

• • • • • What: Storing or handling passwords, tokens insecurely

        • Example: Hardcoded API keys or storing tokens in SharedPreferences (Android)

        • Resolution: Use secure keystore/keychain; never hardcode credentials

02- Inadequate Supply Chain Security

• • • What: Using vulnerable libraries or compromised SDKs

    • Example: App includes a 3rd-party SDK that leaks location data

    • Resolution: Use SBOM, verify dependencies, pin versions, scan with SCA tools

03- Insecure Authentication/Authorization

• • • What: Weak login, session or access control mechanisms

    • Example: No lockout on failed login; insecure token validation

    • Resolution: Use OAuth 2.0/OIDC, MFA, rate limits, token expiry

04- Insufficient Input/Output Validation

• • • What: No validation on inputs or outputs; allows injection attacks

    • Example: App accepts raw user input into SQL query

    • Resolution: Sanitize/validate all inputs, escape outputs

05- Insecure Communication

• • • What: Data transmitted over unprotected channels

    • Example: Sending login over HTTP instead of HTTPS

    • Resolution: Enforce HTTPS, validate TLS certs, use SSL pinning

06- Inadequate Privacy Controls

• • • What: Leaks personal or sensitive user info without consent

    • Example: App accesses microphone/location without informing user

    • Resolution: Follow platform privacy APIs, get explicit user consent

07- Insufficient Binary Protections

• • • What: Easy to reverse engineer and modify the app

    • Example: APK decompiled to extract API keys or disable checks

    • Resolution: Use code obfuscation, root/jailbreak detection, integrity checks

08- Security Misconfiguration

• • • What:Insecure default settings, open debug endpoints

    • Example: Debug flag enabled in production app

    • Resolution: Disable debug mode, secure manifest, validate configs

09- Insecure Data Storage

• • • What: Sensitive data stored insecurely on device

    • Example: Credit card info saved in plain text on device

    • Resolution: Use platform keystore/encrypted storage APIs

10 Insufficient Cryptography

• • What: Weak encryption or misuse of crypto libraries

  • Resolution: Use AES-256 for encryption, PBKDF2/bcrypt/Argon2 for hashing

As the evolution of microservices architecture, the need arises for an OWASP APIs security model that increases the communication between front-end and backend, which OWASP has issues the top 10 vulnerabilities for APIs according to their research for the communities across the world, which can be determined as follows: 

1. API1: Broken Object Level Authorization (BOLA): The whole object

   • Attackers manipulate object IDs (e.g., user IDs) to access data they shouldn’t.

   • Example: User A can fetch User B’s records.

   • Why: Result of not attaching JWT to API scope

   • Solution: RBAC/ABAC
     
     

2. API2: Broken Authentication

   • Weak or missing authentication allows attackers to impersonate users.

   • Example: No MFA, predictable tokens, or missing session validation.

   • Solution: Strengthen you JWT + MFA + short-live token

3. API3: Broken Object Property Level Authorization (BOPLA): Attribute-based

   • APIs expose or allow modification of sensitive fields that users shouldn’t control.

   • Also includes: Excessive data exposure, which was in OWASP 2019 

   • Example: A user updates their role from “user” to “admin” via API.

   • Solution: ABAC/ Prevent automapping
     
     

4. API4: Unrestricted Resource Consumption

   • API doesn’t limit requests → denial of service or high resource usage.

   • Example: No rate limiting or quota enforcement.

   • Solution: Apply both business and technical rate limiting
     
     

5. API5: Broken Function Level Authorization

   • Attackers access sensitive API functions they shouldn’t.

   • Example: Normal user accessing admin-only endpoints.

   • Solution: RBAC
     
     

6. API6: Unrestricted Access to Sensitive Business Flows

   • Business logic is exposed without controls, allowing abuse.

   • Example: Automated checkout bots bypassing purchase limits.

   • Solution: CAPTCHA
     
     

7. API7: Server-Side Request Forgery (SSRF)

   • API fetches a URL supplied by the attacker, letting them reach internal systems.

   • Example: API allows arbitrary URL fetching → attacker scans internal network.
     
     

8. API8: Security Misconfiguration

   • Default, misconfigured, or unnecessary settings expose vulnerabilities.

   • Example: Exposed Swagger UI in production with open API keys.
     
     

9. API9: Improper Inventory Management

   • Shadow APIs or old versions left unprotected.

   • Example: v1 API still active with weak security while v2 is hardened.

   • Concrete repository for API, with versioning
     
     

10. API10: Unsafe Consumption of APIs

• Trusting external APIs blindly without validation.

• Example: App trusts a third-party API response that injects malicious data.