Safety is important for financial products!

Because user safety is important.

Get to know OWASP Top 10 Mobile Application Security Risks (2024)

.

With this admin page, fintech products have to be trained in security all the time and like to pickle this content all the time.

Many of the security standards are OWASP.

So what is it? So what is it? Including the mobile app side. What is it?

.

🔵 OWASP?

OWASP, which stands for Open Worldwide Application Security Project, is a non-profit organization that educates about making computer systems even more secure.

Each year, OWASP announces the Top 10 list. In 2025, it is the web application that he has updated on security earlier in 2017 and 2021.

The section of mobile apps we'll be discussing this as the Top 10 list in 2024 has previous updates in 2014 and 2016.

In addition to the web and mobile, there are others like API security, cloud-native, LLM AI, Privacy. They update them every 3-4 years with the same topics or the same topics combined and new topics. Let us update the rankings according to impact, impact, frequency found.

.

🔵 OWASP Top 10 Mobile Application Security Risks (2024)

So what's in OWASP Mobile Top 10 (2024)?

🗒️ M1: Improper Credential Usage (Improper Credential Management)

⚠️ Risk: Hardcode important data such as API Key, Token or password in Source Code or Settings file, which allows an attacker to perform Reverse Engineer to steal data to attack the backyard system.

🔧 Solution: Do not keep Credential in the Code. Use the Rotate API keys / Tokens strategy consistently and use strong authentication such as Multi-factor authentication.

🗒️ M2: Inadequate Supply Chain Security (Insufficient Supply Chain Security)

⚠️ Risk: Vulnerability caused by an insecure Third-party Library or SDK, including the Build process and app distribution. If the source developer is attacked, our app will also be affected.

🔧 Solution: Select only a trusted and verified Library / SDK and regularly update Patch and check for vulnerabilities (CVEs) in external components.

🗒️ M3: Insecure Authentication / Authorization (Non-Concise Identity / Rights System)

⚠️ Risk: Lax system design allows an attacker to Bypass Authentication or perform Privilege Escalation (elevating permissions from casual users to administrators) to access key functions.

🔧 Solution: The server-side authentication should always be checked and the Roles / Permissions should not be sent directly from the Client side to the backyard system.

🗒️ M4: Insufficient Input / Output Validation (In / Out Data Monitoring, Insufficient)

⚠️ Risk: The app trusts data from unconfirmed sources (such as values from Dropdown or input from users), leading to attacks on SQL Injection, Command Injection or Cross-site Scripting (XSS) types.

🔧 Solution: Validate and Sanitize data on both inbound and outbound sides, both Client and Server for maximum security.

🗒️ M5: Insecure Communication (Insecure Communication)

⚠️ Risk: Sending data over obsolete HTTP or Protocol, allowing an attacker to capture data (Sniffing) or do Man-in-the-Middle (MITM) to modify data en route.

🔧 Solution: Always use the latest standard HTTPS / TLS and should make a Certificate Pinning to prevent spoiling through fake Certificates.

🗒️ M6: Inadequate Privacy Controls (Inadequate Privacy Controls)

⚠️ Risk: Requesting excessive access to personal information (PII), or poor management of access rights, leading to identity theft or violating privacy laws.

🔧 Solution: Request Permission sparingly, give clear notice of purpose, and comply with laws such as PDPA or GDPR by minimizing the collection of information identifying users.

🗒️ M7: Insufficient Binary Protections (Insufficient Binary File Protection)

⚠️ Risk: If the Binary file is unprotected, the poor will be able to reverse Engineering to steal intellectual property or modify the Code to unlock paid features.

🔧 Solution: Use the Binary Obfuscation technique to make the Code difficult to read and perform Integrity Checks to determine if the Code has been tampered with.

🗒️ M8: Security Misconfiguration (Error Security Settings)

⚠️ Risk: Basic security settings are inappropriate, such as leaving Debug mode on or giving over-privileged apps, which opens a channel for the attacker.

🔧 Solution: Take Least Privilege with the permissions required by the app. Turn off Debug mode in the Production version and set the baseline to secure.

🗒️ M9: Insecure Data Storage (Unsafe Data Storage)

⚠️ Risk: Keeping Sensitive Data in Local Storage without encryption or in a place easily accessible to other apps.

🔧 Solution: Use strong encryption and store data in the operating system's Secure Storage, such as Keychain (iOS) or Keystore (Android).

🗒️ M10: Insufficient Cryptography (Non-Standard Data Encryption)

⚠️ Risk: Using old or obsolete Algorithm (e.g., MD5, SHA1), insufficient Key length, or poor Key management process.

🔧 Solution: Use Algorithm that is an international standard (such as AES, high-length RSA). Key Rotation is performed and do not create custom Crypto.

.

🔵 Compared to 2016, what has changed?

8 years apart, of course, a lot of change by

- Change focus: Move from Code Quality security to focus on Credential and Supply Chain instead

- M1 (NEW): Top focus on Hardcoded Secrets protection and API Keys slippage

- M2 & M6 (NEW): Add Vulnerability Monitoring from External Library and Privacy Management (PDPA / GDPR)

- Collapse Combine: Combine Auth / Authz Matters (M3) and Code Unpacking Protection (M7) to make it easier to manage.

- Decreased Sequence: Storage Matters (M9) and Cryptography (M10) Rank OK because modern OSes have better management assist systems.

- Instructions: Developers should stop embedding Passwords in apps, check adopted SDKs, and tighten traffic.

It's all about this.

# Includes IT matters # IT should know # Known IT # programmer # Developer