OWASP Top 10 Mobile- 2024

OWASP Mobile Top 10 Risks: 2024 Edition

The 2024 OWASP Mobile Top 10 reflects a significant restructuring from the 2016 list, consolidating some categories and adding new ones to reflect the current threat landscape for Android and iOS applications.

M1: Improper Credential Usage

Description

Hardcoded credentials, improperly stored secrets, and insecure transmission of authentication credentials remain the leading mobile vulnerability. This category covers:

• API keys, tokens, and passwords hardcoded directly in source code or resource files.
• Credentials stored in plaintext in SharedPreferences, plist files, or SQLite databases.
• Authentication tokens transmitted over HTTP or stored in insecure locations.
• Credentials exposed in log output or error messages.

Mitigation

Never hardcode credentials. Use the platform’s secure storage (Android Keystore, iOS Keychain). Enforce HTTPS for all credential transmission. Implement certificate pinning.

M2: Inadequate Supply Chain Security

Description

Mobile applications depend heavily on third-party SDKs, libraries, and development toolchains. Vulnerabilities in these dependencies directly impact the app.

• Malicious or compromised third-party SDKs.
• Outdated libraries with known vulnerabilities.
• Unverified dependencies or build tools.
• Tampering during the build or distribution pipeline.

Mitigation

Audit all third-party dependencies. Pin dependency versions and verify checksums. Monitor CVE databases for dependency vulnerabilities. Use software composition analysis (SCA) tools.

M3: Insecure Authentication and Authorization

Description

Authentication mechanisms that can be bypassed at the client level or that rely entirely on client-side checks. This includes:

• Authentication decisions made purely in local code (e.g., isAdmin = true in client logic).
• Biometric authentication bypass via runtime instrumentation.
• Broken or missing authorization checks on API endpoints.
• Token-based auth without proper server-side validation.

Mitigation

Enforce all authentication and authorization on the server. Never trust client-supplied privilege claims. Validate tokens server-side on every request.

M4: Insufficient Input/Output Validation

Description

Lack of validation on data received from users, other apps, or the network leads to injection attacks, logic bypasses, and data corruption.

• SQL injection through content providers or deep link parameters.
• JavaScript injection via insecure WebView configuration.
• Intent injection through exported components without input validation.
• XML/JSON injection in API responses processed without validation.

Mitigation

Validate all input at every trust boundary. Use parameterized queries. Sanitize all data displayed in WebViews. Treat data from other apps as untrusted.

M5: Insecure Communication

Description

Data transmitted between the app and backend that is inadequately protected:

• Using HTTP instead of HTTPS.
• Accepting self-signed or expired certificates without warning.
• Disabling certificate validation entirely in code.
• Missing or bypassable certificate pinning.
• Weak TLS configurations (outdated protocol versions, weak cipher suites).

Mitigation

Enforce HTTPS with valid certificates. Implement certificate pinning for sensitive backends. Use Android’s Network Security Configuration or iOS’s App Transport Security. Disable cleartext traffic.

M6: Inadequate Privacy Controls

Description

Collecting, storing, or transmitting more user data than is necessary for the application’s functionality, or failing to adequately protect personal data.

• Excessive permissions requested (camera, contacts, location) beyond functional need.
• PII logged to crash reporting services or analytics.
• Sensitive data included in device backups.
• Screen content cached in the app switcher revealing sensitive information.

Mitigation

Apply data minimization principles. Review all permission requests. Disable backups for sensitive app data. Use FLAG_SECURE to prevent screenshot capture of sensitive screens.

M7: Insufficient Binary Protections

Description

The compiled application binary can be analyzed, modified, and repackaged by an attacker without adequate protections.

• No code obfuscation — class and method names remain readable.
• No tamper detection — modified APK/IPA continues to function normally.
• No anti-debugging measures.
• No root/jailbreak detection.
• Sensitive strings (API keys, encryption keys) visible in the binary.

Mitigation

Apply ProGuard/R8 obfuscation (Android) or equivalent iOS obfuscation. Implement integrity checks. Add root/jailbreak detection. Encrypt sensitive strings in the binary.

M8: Security Misconfiguration

Description

Insecure defaults or misconfigurations in the application or its hosting environment:

• android:debuggable="true" in production builds.
• android:allowBackup="true" exposing app data via ADB.
• Overly permissive exported components (exported="true" without permission protection).
• Insecure Firebase or backend rules permitting unauthenticated reads/writes.
• Excessive permissions in the app manifest.

Mitigation

Review and harden AndroidManifest.xml and Info.plist. Disable debug flags in production. Apply network security configuration. Test exported component access with tools like drozer.

M9: Insecure Data Storage

Description

Sensitive data stored on the device in locations accessible to attackers or other apps:

• Plaintext credentials in SharedPreferences or NSUserDefaults.
• Unencrypted SQLite databases containing PII.
• Sensitive files with world-readable permissions.
• Data stored in external storage (SD card) accessible by other apps.
• Clipboard content with sensitive data.

Mitigation

Use Android Keystore / iOS Keychain for secrets. Encrypt sensitive databases with SQLCipher. Avoid writing sensitive data to external storage. Use EncryptedSharedPreferences (Android).

M10: Insufficient Cryptography

Description

Weak, improperly implemented, or misused cryptography:

• Using MD5 or SHA1 for security-sensitive purposes.
• ECB mode encryption (reveals data patterns through identical ciphertext blocks).
• Hardcoded or predictable encryption keys.
• Using java.util.Random instead of SecureRandom for security-sensitive values.
• Improper IV (initialization vector) reuse in CBC mode.
• Custom cryptography implementations instead of vetted libraries.

Mitigation

Use AES-256 in GCM mode for symmetric encryption. Use RSA-2048+ or ECC for asymmetric operations. Always use SecureRandom for cryptographic key and IV generation. Never roll your own crypto — use platform-provided cryptographic APIs.

OWASP 모바일 Top 10 - 2024: 핵심 가이드

2024년 OWASP 모바일 Top 10은 2016년 목록에서 일부 카테고리를 통합하고 새로운 항목을 추가하여 Android 및 iOS 애플리케이션의 현재 위협 환경을 반영한 중요한 구조 개편을 보여줍니다.

M1: 부적절한 자격 증명 사용 (Improper Credential Usage)

상세 설명

하드코딩된 자격 증명, 부적절하게 저장된 비밀, 안전하지 않은 인증 자격 증명 전송이 여전히 주요 모바일 취약점입니다:

• 소스 코드나 리소스 파일에 직접 하드코딩된 API 키, 토큰, 패스워드.
• SharedPreferences, plist 파일, SQLite 데이터베이스에 평문으로 저장된 자격 증명.
• HTTP로 전송되거나 안전하지 않은 위치에 저장된 인증 토큰.
• 로그 출력이나 에러 메시지에 노출된 자격 증명.

대응 방안

자격 증명을 하드코딩하지 마십시오. 플랫폼 보안 저장소(Android Keystore, iOS Keychain)를 사용하고, 모든 자격 증명 전송에 HTTPS를 강제 적용하십시오. 또한 인증서 피닝 구현 또한 권장됩니다.

M2: 부적절한 공급망 보안 (Inadequate Supply Chain Security)

상세 설명

모바일 애플리케이션은 서드파티 SDK, 라이브러리, 개발 도구체인에 크게 의존합니다. 이러한 의존성의 취약점은 앱에 직접적인 영향을 미칩니다:

• 악의적이거나 손상된 서드파티 SDK.
• 알려진 취약점이 있는 구버전 라이브러리.
• 검증되지 않은 의존성 또는 빌드 도구.
• 빌드 또는 배포 파이프라인 중 변조.

대응 방안

모든 서드파티 의존성을 정기적으로 감사하십시오. 의존성 버전을 고정하고 체크섬을 검증하며, 의존성 취약점에 대한 CVE 데이터베이스를 모니터링하십시오. 소프트웨어 구성 분석(SCA) 도구 사용이 권장됩니다.

M3: 안전하지 않은 인증 및 인가 (Insecure Authentication and Authorization)

상세 설명

클라이언트 수준에서 우회할 수 있거나 완전히 클라이언트 측 검사에 의존하는 인증 메커니즘입니다:

• 로컬 코드에서만 이루어지는 인증 결정(예: 클라이언트 로직에서 isAdmin = true).
• 런타임 계측을 통한 생체 인증 우회.
• API 엔드포인트의 손상되거나 누락된 인가 검사.
• 적절한 서버 측 검증 없는 토큰 기반 인증.

대응 방안

서버에서 모든 인증 및 인가를 강제 적용하십시오. 클라이언트가 제공하는 권한 정보를 절대 신뢰하지 말고, 모든 요청 시 서버 측에서 토큰을 검증해야 합니다.

M4: 불충분한 입출력 검증 (Insufficient Input/Output Validation)

상세 설명

사용자, 다른 앱 또는 네트워크에서 수신한 데이터 검증 부재로 인한 인젝션 공격, 로직 우회, 데이터 손상입니다:

• 콘텐츠 프로바이더나 딥링크 파라미터를 통한 SQL 인젝션.
• 안전하지 않은 WebView 설정을 통한 JavaScript 인젝션.
• 입력 검증 없는 내보내기된 컴포넌트를 통한 인텐트 인젝션.
• 검증 없이 처리되는 API 응답의 XML/JSON 인젝션.

대응 방안

모든 신뢰 경계에서 데이터를 철저히 검증하십시오. 매개변수화된 쿼리를 사용하고, WebView에 표시되는 모든 데이터를 살균(sanitize)하십시오. 다른 앱으로부터 온 데이터는 항상 신뢰할 수 없는 것으로 취급해야 합니다.

M5: 안전하지 않은 통신 (Insecure Communication)

상세 설명

앱과 백엔드 사이에 전송되는 데이터가 적절히 보호되지 않은 경우입니다:

• HTTPS 대신 HTTP 사용.
• 경고 없이 자체 서명되거나 만료된 인증서 수락.
• 코드에서 인증서 검증을 완전히 비활성화한 경우.
• 누락되거나 우회 가능한 인증서 피닝.
• 취약한 TLS 설정(구버전 프로토콜, 취약한 암호 스위트).

대응 방안

유효한 인증서로 HTTPS 사용을 강제하십시오. 민감한 백엔드에 대해서는 인증서 피닝을 구현하고, Android의 네트워크 보안 구성이나 iOS의 App Transport Security(ATS)를 적극 활용하십시오.

M6: 부적절한 개인정보 보호 (Inadequate Privacy Controls)

상세 설명

애플리케이션의 기능에 필요한 것보다 더 많은 사용자 데이터를 수집, 저장 또는 전송하거나 개인 데이터를 적절히 보호하지 못하는 경우입니다:

• 기능적 필요를 초과하는 과도한 권한 요청(카메라, 연락처, 위치).
• 충돌 보고 서비스나 분석 도구에 기록된 개인 식별 정보(PII).
• 기기 백업에 포함된 민감한 데이터.
• 앱 전환기(Task Switcher) 화면 콘텐츠 캐시에 노출되는 민감 정보.

대응 방안

데이터 최소화 원칙을 적용하십시오. 모든 권한 요청을 검토하고, 민감한 앱 데이터의 백업을 비활성화하십시오. 민감한 화면에는 FLAG_SECURE를 적용하여 스크린샷 캡처를 방지하는 것이 좋습니다.

M7: 불충분한 바이너리 보호 (Insufficient Binary Protections)

상세 설명

컴파일된 애플리케이션 바이너리를 공격자가 적절한 보호 없이 분석, 수정 및 재패키징할 수 있는 상황입니다:

• 난독화 없음 — 클래스 및 메서드 이름이 그대로 노출됨.
• 변조 탐지 없음 — 수정된 바이너리가 경고 없이 작동함.
• 안티 디버깅 및 루팅/탈옥 탐지 조치 부재.
• 바이너리 내에 평문으로 존재하는 민감한 문자열(API 키, 암호화 키 등).

대응 방안

ProGuard/R8(Android) 또는 그에 상응하는 난독화 도구를 적용하십시오. 코드 무결성 검사와 루팅/탈옥 탐지 로직을 구현하고, 바이너리 내의 중요 문자열은 반드시 암호화하여 보관하십시오.

M8: 보안 잘못 구성 (Security Misconfiguration)

상세 설명

애플리케이션 또는 호스팅 환경의 안전하지 않은 기본값 또는 잘못된 구성입니다:

• 프로덕션 빌드에서 android:debuggable="true" 설정 유지.
• android:allowBackup="true"로 인해 ADB를 통한 데이터 노출.
• 권한 보호 없이 노출된(Exported) 컴포넌트.
• 비인증 읽기/쓰기를 허용하는 백엔드(Firebase 등) 규칙.

대응 방안

매니페스트 파일(AndroidManifest.xml, Info.plist)을 정기적으로 감사하십시오. 릴리스 빌드에서는 모든 디버그 플래그를 비활성화하고, 네트워크 보안 구성을 적용하십시오. drozer 같은 도구를 사용해 컴포넌트 노출 여부를 점검해야 합니다.

M9: 안전하지 않은 데이터 저장 (Insecure Data Storage)

상세 설명

공격자나 다른 앱이 접근 가능한 위치에 저장된 민감한 데이터입니다:

• SharedPreferences나 NSUserDefaults 내의 평문 정보.
• 암호화되지 않은 SQLite 데이터베이스.
• 모든 사용자가 읽기 가능한 권한으로 설정된 민감한 파일.
• 외부 저장소(SD 카드)에 저장되어 다른 앱이 접근 가능한 데이터.

대응 방안

민감한 정보는 반드시 Android Keystore 또는 iOS Keychain에 저장하십시오. SQLite 데이터베이스는 SQLCipher 등을 이용해 암호화하고, 외부 저장소에 민감한 데이터를 기록하는 것을 피하십시오.

M10: 불충분한 암호화 (Insufficient Cryptography)

상세 설명

취약하거나 부적절하게 구현된, 혹은 오용된 암호화 방식입니다:

• MD5 또는 SHA1을 보안 목적으로 사용.
• 데이터 패턴이 노출되는 ECB 모드 암호화 사용.
• 하드코딩되거나 예측 가능한 암호화 키 사용.
• 보안에 민감한 값 생성 시 SecureRandom 대신 일반 Random 사용.
• 검증되지 않은 커스텀 암호화 알고리즘 구현.

대응 방안

대칭 암호화에는 AES-256(GCM 모드)을, 비대칭 연산에는 RSA-2048+ 또는 ECC를 사용하십시오. 키 생성 시에는 항상 SecureRandom을 사용하고, 독자적인 암호화 로직을 만들기보다 표준 플랫폼 API를 활용해야 합니다.