To the maximum extent permitted under law, CSA and external consultants shall not be liable for any inaccuracies, errors and/ or omissions contained herein nor for any losses or damages of any kind (including any loss of profits, business, goodwill or reputation, and/or any special, incidental or consequential damages) in connection with any use or reliance on this Standard.
Organisations developing mobile apps, service providers and developers are advised to consider how the Standard may be applied to their specific circumstances and obtain their own legal and/or technical advice in relation to the contents and/ or implementation of the recommendations in the Standard Organisations developing mobile apps, service providers and developers should exercise professional judgement if and when implementing the recommendations in the Standard, and should also consider if additional measures are necessary in relation to their specific circumstances.
ACKNOWLEDGEMENTS
These organisations were consulted on the Standard for feedback and comments on the security controls, description of the security controls and technical implementation guidelines.
SAFE APP STANDARD 2.0
The Safe App Standard 2.0 is developed by the Cyber Security Agency of Singapore (CSA) in consultation with industry partners from financial institutions, tech organisations, consultancy firms and government agencies.
The objective of the Standard is to provide a recommended baseline of security controls for mobile app (app) developers and providers. The Standard covers the following eight cybersecurity areas:
1. AUTHENTICATION
2. AUTHORISATION
3. STORAGE
4. ANTI-TAMPERING & ANTI-REVERSING
5. NETWORK COMMUNICATION
6. CRYPTOGRAPHY
7. CODE QUALITY & EXPLOIT MITIGATIONS
8. PLATFORM INTERACTIONS
This will ensure that all local apps adhere to a set of security controls, thereby raising the security levels of the apps hosted and created in Singapore.
INTENDED AUDIENCE
The Standard’s guidelines and security controls will focus primarily on providing security guidelines to developers and providers of high-risk apps to counteract the mobile malware and scam exploits seen in Singapore’s threat landscape. However, these security controls can also benefit and be implemented by other apps. It is recommended that all developers strive to implement these measures for enhanced app security.
DEVELOPER GUIDANCE
The contents herein are non-binding and meant to be informative. They are provided on a nonreliance basis and are not intended to exhaustively identify all potential cybersecurity threats or specify all processes and systems that developers should use to address or prevent such threats. This is a living document that will be subjected to review and revision periodically. Like many other established standards, the Standard will be regularly updated to match the current and evolving threat landscape and new attack vectors. Ultimately, app developers and owners are responsible for staying abreast of the latest industry best practices to implement controls stated in this Standard.
The Standard recommends security controls and the upgrading of legacy systems to protect apps effectively. However, app developers and providers are ultimately responsible for conducting risk management that balances security and usability concerns. In addition, app developers should perform their due diligence and exercise their discretion to exclude controls that do not apply to their apps.
REQUIREMENTS NOTATION AND CONVENTION
The term “SHOULD” indicates that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
DOCUMENT DEFINITIONS
The following are some definitions that readers should keep in mind as they utilise this document:
High-risk apps are those with transactions that can lead to significant financial losses. These highrisk transactions include:
• Changes to financial functions – some examples include but are not limited to registration of third-party payee details, increase of fund transfer limit, etc.
• Initiation of financial transactions – some examples include but are not limited to high-value funds transactions, high-value funds transfers, online card transactions, direct debit access, money storage functions, top-ups, etc.
• Changes to the app’s security configurations– some examples of this include but are not limited to disabling authentication methods, updating digital tokens or credentials, etc.
Security controls are operational or technical measures recommended in this document that should be implemented to manage, monitor and mitigate potential security vulnerabilities or incidents. These security controls have the following IDs attached to them, such as AUTHN-BP01, AUTHOR-BP01, STORAGE-BP01, RESILIENCE-BP01.
Sensitive data are user data such as Personal Identifiable Information (PII) and authentication data such as credentials, encryption keys, one-time passwords, biometric data, security tokens, certificates, etc.
LEGAL NOTICE
This Standard should be read in conjunction with and does not replace, vary, or supersede any legal, regulatory or other obligations and duties of app developers and providers, including those under the Cybersecurity Act 2018 and any subsidiary legislation, codes of practice, standards of performance or written directions issued thereunder. The use of this document and implementation of the recommendations herein also does not exempt or automatically discharge the app developer and provider from any such obligations or duties. The contents of this document are not intended to be an authoritative statement of the law or a substitute for legal or other professional advice.
CHANGELOG
• 4 cybersecurity areas have been added.
• AUTHN-BP01 and AUTHOR-BP03 have been enhanced to emphasise the intent of the controls.
• AUTHN-BP01a has been adjusted for better alignment with the industry.
• RESILIENCE-BP07 has been repositioned to PI-BP03 for better alignment.
• Content has been refined to improve readability.
Apps often have user accounts that users can log into to access personalised data, make transactions, manage personal finances and perform other actions on user information and resources. However, since these digital accounts provide access to sensitive data and finances, attackers constantly attempt to gain unauthorised access by stealing credentials and impersonating users.
Controls in authentication ensure the authenticity of users and the confidentiality, integrity and privacy of sensitive data. This involves employing multiple layers of authentication, including inherence-, possession- and knowledge-based factors, to validate user identity. Additionally, the controls secure user sessions and authentication processes.
such as a trusted hardware device, a SIM card or an email account. Users then present generated One-Time Passwords (OTPs) or cryptographic keys as proof of possession.
o Inherence-based factors (AUTHN-BP01c) as “something you are”, are biometric identifiers that rely on users’ unique physical characteristics. These factors include authentication methods such as fingerprint, retina, facial or voice scans.
Authentication Authentication Risk of Account Takeover Factor Methods Through Stolen Credentials
Knowledgebased
Memorised Secrets such as passwords or passphrases
One-Time Password such as SMS or email OTP
Possessionbased
Cryptographic Key such as PKI certificates or Passkeys
Inherencebased Biometrics such as fingerprint or facial verification
High Risk
Method is vulnerable to phishing. Attackers can use fake websites to trick users into giving up their memorised secrets.
Medium Risk
Method is vulnerable to real-time phishing. Attackers can use fake websites to trick users into giving up their OTP and replay them in real-time.
Low Risk
Method is resistant to phishing. It is difficult for attackers to access or steal cryptographic keys stored in secured elements on mobile devices.
Low Risk
Method is resistant to phishing. It is difficult for attackers to access or steal biometric data stored in secured elements on mobile devices.
The overall MFA risk is determined by the most vulnerable authentication method used. For example, combining a password (high risk) with fingerprint verification (low risk) does not mitigate the inherent vulnerabilities of passwords, thereby undermining the effectiveness of MFA.
To achieve optimal security, minimise risks across all authentication factors. For instance, using a combination of Passkeys (low risk) and facial verification (low risk) employs two phishingresistant methods, significantly reducing the likelihood of account compromise through stolen credentials.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Authentication Architectures, General Guidelines on Testing Authentication, page 51,
o Mobile App Authentication Architectures, Two-factor Authentication, page 56.
• Android Developers, Identity, Guides, Add a sign-in workflow, https://developer.android.com/identity/sign-in.
• Apple Developer, Documentation, Authentication Services, https://developer.apple.com/documentation/AuthenticationServices.
• Apple Developer, Documentation, Local Authentication, https://developer.apple.com/documentation/LocalAuthentication.
Knowledge-based authentication involves using information known only to the user, such as a Personal Identification Number (PIN), password or pattern, to verify the user’s identity. However, if this information is easy to guess, attackers can use attacks, such as brute force attacks and credential stuffing, to gain unauthorised access to users’ accounts.
Developers should implement knowledge-based authentication securely, which includes implementing a robust password policy. This security control protects the authenticity of the user and the confidentiality, integrity and privacy of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Allow only passwords with a length of 12 characters or more,
• Set a reasonable maximum password length,
• Reject passwords with personal details,
• Reject passwords with sequential characters, such as “123456”, or repeated characters, such as, “aaaaa”, and
• Reject guessable words, phrases or combinations.
ADDITIONAL NOTES
Enforce credential rotation when deemed appropriate, such as upon evidence of a security breach or compromise.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-AUTH-1 and MASVS-AUTH-3.
• MAS Technology Risk Management Guidelines (January 2021), section(s) 9.1.4.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 2.3.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Authentication Architectures, General Guidelines on Testing Authentication, page 51.
• NIST Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management (June 2017), section(s) 5.1.1.2.
AUTHN-BP01b AUTHENTICATION
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-AUTH-1 and MASVS-AUTH-3.
• MAS Technology Risk Management Guidelines (January 2021), section(s) 14.2.5 and 14.2.8.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 2.5.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Authentication Architectures, Two-factor Authentication, page 56-58.
• NIST Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management (June 2017), section(s) 5.1.4.
AUTHN-BP01c AUTHENTICATION
Implement inherence-based authentication securely
DESCRIPTION
Inherence-based authentication involves using biometric identifiers such as fingerprints, retina scans or facial recognition, to verify the user’s identity. However, malicious attackers can use biometric data to gain unauthorised access to users’ accounts.
Developers should implement inherence-based authentication securely. This security control protects the authenticity of the user and the confidentiality, integrity, and privacy of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Use server-side biometric authentication – Use a trusted server-side biometric identification platform such as Singpass. However, if infeasible, utilise the device’s Trusted Execution Environments (TEEs) mechanisms, such as “CryptoObject” and Android Protected Confirmation for Android or Keychain services for iOS, to implement client-side biometric authentication.
• Invalidate authentication upon changes – Invalidate biometric authentication if changes occur in the biometric mechanism, such as enrolling a new fingerprint on the device. Both iOS and Android platforms support setting an app crypto key to expire in response to such changes.
ADDITIONAL NOTES
Limit apps’ functionalities on devices lacking hardware TEE or biometrics.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-AUTH-1, MASVS-AUTH-2, and MASVS-AUTH-3.
• MAS Technology Risk Management Guidelines (January 2021), section(s) 14.2.6, and 14.2.11.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 2.1, 2.10, 2.12, 3.6, 13.4 and 13.7.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Local Authentication, page 227-233,
o iOS Local Authentication, page 442-426.
AUTHN-BP02
Use context-based factors to authenticate
DESCRIPTION
Digital authentication allows users to log in from wherever they are because authentication is not bound to a specific physical location. Credentials can be used on any device with Internet access, providing flexibility and convenience for users. However, this allows attackers to remotely compromise user accounts.
Developers should use context-based factors to authenticate, by introducing dynamic elements such as user location and device attributes. This security control protects the authenticity of the user and the confidentiality, integrity and privacy of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Check device’s geolocation – Allow access based on the real-world location of a device using GPS, Wi-Fi or IP address geolocation.
• Check device type – Allow access based on the characteristics of a device. For example, the screen size can determine if a device is a smartphone or tablet.
REFERENCES
This security control is referenced from the following standards:
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 2.9.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Authentication Architectures, Supplementary Authentication, page 56,
o Mobile App Authentication Architectures, Login Activity and Device Blocking, page 58.
AUTHN-BP03 AUTHENTICATION
Implement secure session authentication
DESCRIPTION
Session authentication allows a user to remain authenticated across multiple interactions in an app, enabling them to access and perform actions on protected resources or sensitive data without re-submitting credentials for each interaction. However, attackers can manipulate and hijack sessions to gain unauthorised access to sensitive data.
Developers should implement secure session authentication. This security control protects the authenticity of the user and the confidentiality, integrity and privacy of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Implement secure stateful authentication (AUTHN-BP03a), which refers to the management of session states on the server side, typically requiring the use of session identifiers.
• Implement secure stateless authentication (AUTHN-BP03b) which refers to the management of sessions without storing user-related information on the server side.
REFERENCES
This security control is referenced from the following standards:
• MAS Technology Risk Management Guidelines (January 2021), section(s) 14.2.9.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 2.6.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Authentication Architectures, Stateful vs. Stateless Authentication, page 51-55.
Stateful authentication involves managing session states on the server side, typically using session identifiers. While stateful authentication provides a seamless user experience through persistent user sessions, attackers can steal session identifiers to hijack sessions to gain unauthorised access to sensitive data.
Developers should implement secure stateful authentication. This security control protects the authenticity of the user and the confidentiality, integrity and privacy of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Identify server-side endpoints that expose sensitive data or critical functionalities,
• Reject requests with missing or invalid session IDs or tokens,
• Generate session IDs randomly on the server side without appending them to URLs,
• Enhance session ID security with proper length and entropy, making guessing difficult,
• Exchange session IDs only over secure HTTPS connections,
• Avoid storing session IDs in persistent storage,
• Verify session IDs for user access to privileged app elements, and
• Terminate sessions on the server side, deleting session information upon timeout or logout.
ADDITIONAL NOTES
If in doubt, use trusted authentication platforms and protocols.
REFERENCES
This security control is referenced from the following standards:
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 2.6, 2.7, 2.8 and 2.14.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Authentication Architectures, Stateful vs. Stateless Authentication, Stateful Authentication, page 52.
AUTHN-BP03b
Implement secure stateless authentication
DESCRIPTION
Stateless authentication involves managing sessions without storing user-related information on the server, but instead, tokens are sent by the app after authentication to verify the user’s identity. However, attackers can intercept, steal or forge tokens to impersonate the user to gain unauthorised access to sensitive data.
Developers should implement secure stateless authentication. This security control protects the authenticity of the user and the confidentiality, integrity and privacy of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Generate tokens on the server side without appending them to URLs,
• Enhance token security with proper length and entropy to make guessing difficult,
• Exchange tokens only over secure HTTPS connections,
• Verify that no sensitive data is embedded in the token,
• Avoid storing tokens in persistent storage,
• Verify tokens for user access to privileged app elements,
• Terminate tokens on the server side,
• Delete token information upon timeout or logout, and
• Sign tokens cryptographically using a secure algorithm and avoid the use of null algorithms.
ADDITIONAL NOTES
If in doubt, use trusted authentication platforms and protocols.
REFERENCES
This security control is referenced from the following standards:
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 2.6, 2.7, 2.8 and 2.14.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Authentication Architectures, Stateful vs. Stateless Authentication, Stateless Authentication, page 52-53.
Implement secure session termination during logout, inactivity or app closure
DESCRIPTION
Session termination involves ending a user’s authenticated session, after which the user is required to re-authenticate. If not terminated after a specified duration, attackers can exploit such sessions to gain unauthorised access to sensitive data.
Developers should implement secure session termination during logout, inactivity or app closure. This security control protects the authenticity of the user and the confidentiality, integrity and privacy of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Reauthenticate users after logging out, app inactivity, idleness, backgrounding, absolute session timeouts or abrupt/force closure,
• Generate new session identifiers on the server whenever users move up to a new authentication level to prevent session fixation, and
• Clear and deauthorise all locally stored tokens or session identifiers.
ADDITIONAL NOTES
Determine the idle timeout value based on the risk and nature of app transactions.
REFERENCES
This security control is referenced from the following standards:
• MAS Technology Risk Management Guidelines (January 2021), section(s) 14.2.9.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 2.14, 2.15 and 2.16.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Authentication Architectures, User Logout, page 55-56,
o Mobile App Authentication Architectures, Login Activity and Device Blocking, page 58.
Implement brute force protection for authentication
DESCRIPTION
Many authentication mechanisms require user input, such as passwords and PINS. However, these inputs have a fixed number of combinations or common inputs. Attackers perform brute force attacks involving automated and systematic attempts to guess user credentials, such as trying various combinations of usernames and passwords, to gain unauthorised access.
Developers should implement brute force protection for authentication by restricting the number of login attempts within a specified period. This security control protects the authenticity of the user and the confidentiality, integrity and privacy of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Implement anti-automation checks,
• Apply rate limiting for login attempts,
• Incorporate progressive incremental time delays, such as 30 seconds, 1 minute, 2 minutes and 5 minutes, for login attempts, and
• Enforce account lockouts.
ADDITIONAL NOTES
All MFA mechanisms are vulnerable to brute force.
Inform users why their account is locked out and provide accessible means for them to reauthenticate and deactivate the lockout. For example, allow users to call a helpline or utilise biometric verification.
REFERENCES
This security control is referenced from the following standards:
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 2.5 and 5.7.
Details of security best practices are referenced from the following documents:
While authentication ensures the user’s identity, it does not eliminate the possibility of fraudulent activities during the transaction process. Attackers who successfully compromise accounts may perform unauthorised transactions without the user’s knowledge.
Developers should implement transaction integrity verification mechanisms, which are auxiliary security functions, to give users the time and tools to react to potential frauds. This security control protects the authenticity of the user and transactions.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Initiate a transaction verification or confirmation call,
• Provide a real-time transaction history,
• Implement a cooldown period of 12 hours to 24 hours,
• Disable overseas transactions by default and enable only through MFA, and
• Allow users to terminate active sessions.
REFERENCES
This security control is referenced from the following standards:
• MAS Technology Risk Management Guidelines (January 2021), section(s) 14.3.1, 14.3.3 and 14.4.3.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Authentication Architectures, Two-factor Authentication, Transaction Signing with Push Notifications and PKI, page 57-58.
Apps use permissions and access rights to determine the appropriate access to resources, features or data. Likewise, users can authorise apps with permissions to use certain functions on their devices. However, attackers can bypass poorly configured authorisation by manipulating permissions to gain unauthorised access to sensitive data or perform actions without user consent.
Controls in authorisation ensure the confidentiality, integrity and privacy of sensitive data; and the integrity of actions performed. This involves securely implementing authorisation on both the server- and clientsides and ensuring transparency between the app and users.
ID CONTROL
AUTHOR-BP01 Implement server-side authorisation.
AUTHOR-BP02 Implement client-side authorisation via device binding.
AUTHOR-BP03 Request minimal permissions.
AUTHOR-BP04 Notify users of all highrisk transactions that have been authorised and completed.
Implement server-side authorisation
DESCRIPTION
Authorisation refers to the validation and accordance of access permissions to users or apps. However, the portable nature of devices and apps allows attackers to manipulate and bypass the authorisation process. By modifying access control decisions, attackers can gain unauthorised access to sensitive data and perform unauthorised actions.
Developers should implement server-side authorisation to enforce permissions on the server-side. This security control protects the confidentiality, integrity and privacy of sensitive data; and the integrity of actions performed.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Implement server-side authorisation after successful authentication and before granting access permissions,
• Grant permissions based on assigned roles, ensuring users can only perform tasks relevant to their responsibilities, and
• Grant permissions based on dynamic contextual factors such as time of access and behavioural analysis.
REFERENCES
This security control is referenced from the following standards:
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 1.4, 2.1, 2.9 and 2.19.
• PCI Mobile Payment Acceptance Security Guidelines for Developers v2.0 (September 2017), section(s) 4.2.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Authentication Architectures, OAuth, page 53-55.
AUTHOR-BP02 AUTHORISATION
Implement client-side authorisation via device binding
DESCRIPTION
When the app’s business functions require authorisation to be performed on the client-side, it manages access permissions within an app. This is risky as reliance on client-side authorisation exposes the process to attackers who can manipulate it to gain unauthorised access to sensitive data and perform unauthorised actions.
Developers should implement client-side authorisation via device binding which associates authorisations to access privileges on a particular device. This allows apps to verify the device’s identity and establish trust. This security control protects the confidentiality, integrity and privacy of sensitive data; and the integrity of actions performed.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Establish binding between the app and the device when a user’s identity is used for the first time on an unregistered device,
• Check for modifications to the device since the last runtime,
• Check for modifications to the device identity markers, and
• Check that the device running the app is in a secure state, such as not rooted or jailbroken.
ADDITIONAL NOTES
When verifying device binding on Android devices, implement the following:
• Obtain unique identifiers like IMEI or Android ID,
• Retrieve build information, and
• Leverage native OS API features, such as Google’s SafetyNet.
When verifying device binding on iOS devices, implement the following:
• Leverage native OS services, such as Apple’s device ID, via UIDevice.
REFERENCES
This security control is referenced from the following standards:
• MAS Technology Risk Management Guidelines (January 2021), section(s) 14.2.8 and C.1g.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Anti-Reversing Defenses, Overview, Device Binding, page 316-317,
o iOS Platform APIs, Checking for Weaknesses in Third Party Libraries, Device Binding, page 516.
AUTHOR-BP03 AUTHORISATION
Request minimal permissions
DESCRIPTION
Apps may require access to data stored on the device and actions to use the device’s features. For example, some apps may need to store or process data from the calendar, contacts or gallery, while other apps may need to use the device’s camera, GPS or Bluetooth. However, attackers may exploit unnecessary permissions requested, such as Android accessibility services, to compromise the device.
Developers should request minimal permissions to prevent users from unknowingly granting excessive permissions. This security control protects the integrity of the device and the transparency between users and the app.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Request only the absolute minimum number of permissions to resources for the app to function,
• Communicate all required permissions clearly to users,
• Explain to users why the required permissions are needed, and
• Allow users to manage the duration, such as always or only while using the app, and the scope, such as specific or full access, of permissions.
ADDITIONAL NOTES
Use real-time indicators, which are available in Android 12 and iOS 14 or later, to inform users when the microphone or camera is being used by the app.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-PRIVACY-1.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Platform APIs, Testing for App Permissions, page 261-264,
o iOS Platform APIs, Testing App Permissions, page 469-474.
• Android Developers, Develop, Guides, Permissions on Android, https://developer.android.com /guide/topics/permissions/overview.
• Apple Developer, Documentations, UIKit, Protecting the User’s Privacy, Requesting access to protected resources, https://developer.apple.com/documentation/uikit/protecting_the_user_s _privacy/requesting_access_to_protected_resources
AUTHOR-BP04
Notify users of all high-risk transactions that have been authorised and completed
DESCRIPTION
While authorisation ensures permission control, it does not eliminate the possibility of fraudulent activities during the transaction process. Attackers who successfully compromise accounts may perform unauthorised transactions without the user’s knowledge.
Developers should notify users of all high-risk transactions that have been authorised and completed. Users are immediately made aware of transactions to identify fraudulent transactions as soon as possible. This security control protects the integrity of actions performed, the privacy of users and transparency between users and the app.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Alert users using in-app alerts, email notifications or Short Message Service (SMS) notifications, and
• Remove sensitive data from notifications and alerts.
REFERENCES
This security control is referenced from the following standards:
• MAS Technology Risk Management Guidelines (January 2021), section(s) 14.3.3.
• PCI Mobile Payment Acceptance Security Guidelines for Developers v2.0 (September 2017), section(s) 4.2.
Details of security best practices are referenced from the following documents:
• Apple Developer, Design, Privacy, https://developer.apple.com/design/human-interfaceguidelines/privacy.
Apps store significant amounts of data to provide users with quick access to information, offline functionalities and personalised experiences. However, given the sensitive nature of data that is retained, attackers attack databases and file systems on both devices and servers to exfiltrate sensitive data.
Controls in data storage ensure the confidentiality and integrity of sensitive data stored by the app. This involves storing only necessary data, encrypting the data on both the server- and client-sides and deleting data when no longer needed.
ID CONTROL
STORAGE-BP01 Store sensitive data only when necessary for transactions.
STORAGE-BP02 Implement secure storage of sensitive data.
STORAGE-BP02a Store sensitive data securely on the server-side.
STORAGE-BP02b Store sensitive data securely on the client-side in a Trusted Execution Environment (TEE).
STORAGE-BP03 Delete sensitive data when no longer necessary.
STORAGE-BP01 DATA STORAGE (DATA-AT-REST)
Store sensitive data only when necessary for transactions
DESCRIPTION
Apps that provide personalised functionalities often use sensitive data to allow users to perform actions such as financial transactions. However, the storage of unnecessary sensitive data makes an app an attractive target for attackers, since attackers can compromise the device and exfiltrate such data for use in other attacks.
Developers should store sensitive data only when necessary for transactions. This security control protects the privacy of users.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Classify data being used by the app based on an organisation’s sensitivity levels and legal requirements,
• Implement a secure storage solution based on its sensitivity on the client-side and server-side,
• Apply data protection measures, such as tokenising, hashing with salt and encrypting, on sensitive data, and
• Delete sensitive data when no longer necessary.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-STORAGE-2.
• MAS Technology Risk Management Guidelines (January 2021), section(s) 3.3.1, 10.1.2, 11.1.1c and 11.1.7.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 1.1 and 7.13.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Data Storage, Overview, page 190,
o iOS Data Storage, Overview, page 398.
STORAGE-BP02 DATA STORAGE (DATA-AT-REST)
Implement secure storage of sensitive data
DESCRIPTION
Sensitive data used by apps are stored either on the app server or the device itself, from which the app accesses and uses the data. However, attackers can compromise either storage location to exfiltrate sensitive data to use in other attacks.
Developers should implement the secure storage of sensitive data. This security control protects the confidentiality and integrity of sensitive data; and the privacy of users.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Implement a secure storage solution that is commensurate with the sensitivity of data,
• Store all sensitive data on the server-side (STORAGE-BP02a), and
• Store all sensitive data in the client-side Trusted Execution Environment (TEE), only if storage on the server-side is not possible (STORAGE-BP02b).
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-STORAGE-1.
• MAS Technology Risk Management Guidelines (January 2021), section(s) 11.1.3.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 1.1 and 1.2.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Data Storage, Overview, page 190-203,
o iOS Data Storage, Overview, page 398-406.
tokenisation service to substitute sensitive data with tokens where possible. Use tokenisation of sufficient length and complexity, backed by secure cryptography and based on data sensitivity and business needs.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-CRYPTO-1.
• MAS Technology Risk Management Guidelines (January 2021), section(s) 11.1.3.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 1.5 and 7.14.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Cryptography, page 71-77,
o Android Cryptographic APIs, 219-227,
o iOS Cryptographic APIs, 416-421.
DATA STORAGE (DATA-AT-REST)
STORAGE-BP02b
ADDITIONAL NOTES
Consider using virtualised TEEs for devices without hardware TEEs. Alternatively, disable the app if the device is deemed insecure for high-risk transactions.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-CRYPTO-1.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Data Storage, Overview, KeyStore, Cleaning out Key Material, page 199,
o Android Data Storage, Testing Local Storage for Sensitive Data, page 206-208,
o Android Data Storage, Testing Memory for Sensitive Data, page 208-214,
o iOS Data Storage, Overview, Keychain Data Persistence, page 403-405,
o iOS Data Storage, Checking Logs for Sensitive Data, page 406,
o iOS Data Storage, Testing Local Data Storage, page 407-409,
o iOS Data Storage, Testing Backups for Sensitive Data, 410-414.
Apps are often distributed publicly, allowing attackers to analyse, reverse engineer and tamper with them. Attackers would redistribute the modified apps to victims, where they can steal credentials or modify app behaviour, leading to the leaking of sensitive data and financial losses for users.
Controls in anti-tampering and anti-reversing ensure the integrity of apps and their functionalities. This involves ensuring that the app is not running on compromised platforms, or platforms that facilitate reverse engineering. Additionally, the controls ensure that different types of tampering, either on the source code or during runtime, are detected and defended against.
ID CONTROL
RESILIENCE-BP01 Sign app with certificates from official app stores.
RESILIENCE-BP02 Implement root and jailbreak detection.
RESILIENCE-BP06 Implement overlay, remote viewing and screenshot countermeasures.
RESILIENCE-BP01
Sign app with certificates from official app stores
DESCRIPTION
Apps are publicly distributed online to maximise reach to the users. However, attackers can tamper with apps and re-distribute them as spoofed apps via less strictly regulated channels. This allows attackers to use these unauthorised apps to collect sensitive data or infect the victim’s device with malware.
Developers should sign their apps with certificates provided by official app stores to assure mobile operating systems (OSes) and users that the apps are from verified sources and have not been tampered with. Mobile OSes can also determine whether to run or install software based on the signatures or certificates used to sign the code, preventing the installation and execution of potentially harmful apps. This security control protects the integrity and authenticity of apps.
IMPLEMENTATION GUIDANCE
For apps on Google’s Play Store, implement best practices, such as the following:
• Configure Play App Signing – Signing apps on Google Play is a requirement for distribution through Google’s Play Store.
• Use Google Play’s Play Integrity API – Utilise the application integrity field to validate that the app and its certificate match the versions distributed by Google Play. Additionally, utilise the account details field to ensure that the app was installed by the user from Google Play, rather than being sideloaded.
For apps on Apple’s App Store, implement best practices, such as the following:
• Enrol in the Apple Developer Programme developer portal.
For apps on other official app stores, refer to their respective developer guidelines on app source code signing.
ADDITIONAL NOTES
This security control is a requirement for publishing apps on official app stores.
RESILIENCE-BP02
Implement root or jailbreak detection
DESCRIPTION
Rooted and jailbroken devices are generally considered insecure. Rooted or jailbroken devices allow users to gain elevated privileges, enabling easier circumvention of security and OS limitations. Such elevated privileges can be unsafe for apps as these privileges allow attackers to potentially exploit vulnerabilities, steal credentials, take over user devices and execute fraudulent app transactions.
Developers should implement root or jailbreak detection using indicators of elevated privileges. This security control protects the integrity of app processes and systems.
IMPLEMENTATION GUIDANCE
For Android devices, implement best practices, such as the following:
• Check for superuser or SU binary,
• Detect root file system changes,
• Look for rooted apps,
• Check for custom recovery,
• Check for unsafe API usage, and
• Use Google Play’s Play Integrity API – Utilise the device integrity field to detect system compromise, such as being rooted, in the device that your app is running on.
For iOS devices, implement best practices, such as the following:
• Detect the use of restricted APIs,
• Look for jailbreak tweaks like mods,
• Look for unofficial app store signatures such as Cydia App Store,
• Look for kernel modifications,
• Check for the integrity of the critical file systems, and
• Use 3rd-party libraries designed to detect device tampering.
RESILIENCE-BP03 ANTI-TAMPERING &
Implement emulator detection
DESCRIPTION
Emulators are software used to test apps by allowing a user to test an app on a variety of mimicked mobile versions and devices. However, outside of the development environment, attackers can conduct dynamic analysis, rooting, debugging, instrumentation, hooking and fuzz testing on an emulated device they can control. This allows them to discover vulnerabilities within the app for exploitation.
Developers should implement emulator detection and disallow their apps to be mounted on emulators outside of the development environment. This security control protects the integrity of the app and its processes.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Check battery usage,
• Check timestamps and clocks,
• Check multi-touch behaviours,
• Check memory and performance analysis,
• Perform network checks,
• Check whether it is hardware-based,
• Check what the OS is based on,
• Check for device fingerprints,
• Check build configurations, and
• Check for emulator services and apps.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-RESILIENCE-4.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Anti-Reversing Defenses, Testing Emulator Detection, page 325,
o iOS Platform APIs, Testing Emulator Detection, page 521.
RESILIENCE-BP04
Implement malware detection
DESCRIPTION
Malware apps are increasingly used by attackers as a vector to compromise users’ devices. Malware apps primarily utilise sideloading features as a channel to get users to install malware on their devices. Malware apps can also target legitimate apps by exploiting app and OS vulnerabilities to steal credentials, take over the device and execute fraudulent transactions.
Developers should implement malware detection capabilities on an app at runtime and prevent users from being exploited via malware. This security control protects the integrity of apps and their processes, as well as the confidentiality and privacy of users’ sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Incorporate a Runtime Application Self-Protection (RASP) Software Development Kit (SDK) into their apps,
• Utilise RASP SDKs to check for and detect malware apps at runtime,
• Check for and prevent overlays,
• Prevent clickjacking,
• Prevent app memory hooking, and
• Disable the app upon detecting malicious activities – Upon the deactivation of the app, provide the user with the necessary information on why the app has been disabled and inform the user to uninstall the malware on their device. Alternatively, warn the user and disable highrisk functions on the app until the user remediates the malware.
For Android devices, implement the following best practices:
• Use Google Play’s Play Integrity API malware on the device.
ADDITIONAL NOTES
Since RASP SDKs are third-party dependencies, adopt best practices when implementing secure RASP SDKs. Refer to CQEM-BP03b.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-RESILIENCE-1.
• MAS Technology Risk Management Guidelines (January 2021), section(s) 11.3.3 and 11.3.5.
• PCI Mobile Payment Acceptance Security Guidelines for Developers v2.0 (September 2017), section(s) 4.12.
Details of security best practices are referenced from the following documents:
• NIST Special Publication 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations (September 2020), section(s) 3.19.SI-8.17.
• Android Developers, Google Play, Play Integrity, Integrity verdicts, Environment details field, https://developer.android.com/google/play/integrity/verdicts#environment-details-field
RESILIENCE-BP05
Implement anti-hooking mechanisms
DESCRIPTION
Hooking refers to a technique used by attackers to intercept or modify the behaviour of an app at runtime. This involves inserting or hooking into the execution flow of an app to either monitor its activities, alter its behaviour, inject malicious code or modify existing code functions to exploit vulnerabilities.
Developers should implement anti-hooking mechanisms on apps and prevent unauthorised access, protect high-risk transaction operations, detect and prevent tampering and modification attempts, preserve intellectual property and maintain app reliability. This security control protects the integrity of apps and their processes.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Implement mechanisms to block code injections,
• Implement mechanisms to prevent method hooking by preventing modifications to the app source code on both the client and server,
• Implement mechanisms to prevent the execution of modified codes in the app,
• Implement mechanisms to prevent memory access and memory manipulation of the app,
• Implement tamper-resistant algorithms or anti-tampering Software Development Kits (SDKs) such as Runtime Application Self Protection (RASP) SDKs, and
• Check for insecure parameters such as obsolete APIs and parameters.
For Android devices, implement the following best practices:
• Use Google Play’s Play Integrity API –attack, such as API hooking, on the device that their app is running on.
ADDITIONAL NOTES
Obfuscate the app’s code to make it harder for attackers to understand and reverse engineer. Although obfuscation alone is insufficient to prevent tampering and should not be implemented on its own, it significantly increases the difficulty for attackers and enhances overall security.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-RESILIENCE-2.
• MAS Technology Risk Management Guidelines (January 2021), section(s) C.1c.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 11.2.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Security Testing, Method Hooking, page 135-140,
o Android Security Testing, Repacking Apps, page 189,
• Android Developers, Google Play, Play Integrity, Integrity verdicts, Device integrity field, https://developer.android.com/google/play/integrity/verdicts#device-integrity-field
RESILIENCE-BP06
Implement overlay, remote viewing and screenshot countermeasures
DESCRIPTION
Apps utilise the device’s display to convey information and sensitive data to users. However, any information displayed on the screen can be captured or recorded without the user’s explicit consent when an app has screen recording, screenshot or overlay functionalities. For example, overlay attacks deceive users by creating a fake layer mimicking trusted apps, aiming to steal sensitive data. Additionally, remote viewing attacks involve unauthorised access to a device’s screen, allowing attackers to harvest sensitive data remotely. Screenshot attacks can also occur when attackers capture a device’s screen without user consent, extracting sensitive data.
Developers should implement overlay, remote viewing and screenshot countermeasures and ensure that sensitive data displayed on the app cannot be captured by malware. This security control protects the privacy of users and safeguards sensitive data against inadvertent loss or misuse.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Use RASP SDKs – Runtime Application Self Protection (RASP) Software Development Kits (SDKs) prevent malicious apps from utilising overlays and remote viewing exploits.
• Block screenshot capabilities – Utilise the “FLAG_SECURE” flag for Android apps and similar flags for iOS to block out all screenshot capabilities when using the app. If certain business functions require screenshot capabilities, such as taking a screenshot of a completed PayNow transaction, disable screenshot capabilities for screens or pages that include sensitive data.
• Protect information when the app is backgrounded screens when the app is backgrounded.
For Android devices, implement the following best practices:
• Use Google Play’s Play Integrity API –on the device with permissions enabled that can be used for screen capturing and displaying overlays on the app.
ADDITIONAL NOTES
Some examples of pages where screenshot capabilities should be disabled include but are not limited to, login pages, multi-factor authentication pages, security credentials and PII changing pages.
Furthermore, since RASP SDKs are third-party dependencies, adopt best practices when implementing secure RASP SDKs. Refer to CQEM-BP03b.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-RESILIENCE-2, and MASVS-PLATFORM-3.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 1.22, 1.23 and 12.4.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Security Testing, Accessing the Device Shell, page 166-168,
o Android Platform APIs, Overview, Overlay Attacks, page 257,
o Android Platform APIs, Testing for Overlay Attacks, page 259-260,
o Android Platform APIs, Finding Sensitive Information in Auto-Generated Screenshots, page 265-267,
o iOS Security Testing, Accessing the Device Shell, page 366-367,
o iOS Platform APIs, Testing for Auto-Generated Screenshots for Sensitive Information, page 480.
• Android Developers, Google Play, Play Integrity, Integrity verdicts, Device integrity field, https://developer.android.com/google/play/integrity/verdicts#device-integrity-field.
Apps communicate data to their servers for various purposes such as data synchronisation, authentication, authorisation or transaction processing. Attackers can intercept such communication to eavesdrop and steal sensitive data or modify data.
Controls in network communication ensure the confidentiality and integrity of data that is in transit over the network. This involves encrypting data with secure protocols and authenticating the user’s device to safeguard sensitive data and prevent unauthorised access.
NETCOM-BP01 NETWORK COMMUNICATION (DATA-IN-TRANSIT)
Use secure communication protocols
DESCRIPTION
Apps use various network communication protocols such as Transmission Control Protocol (TCP) and HyperText Transfer Protocol (HTTP). Attackers can intercept these communications to exfiltrate or tamper with data, which may lead to unauthorised access.
Developers should use secure communication protocols to ensure the secure exchange of information over a network. This involves using secured versions of these protocols, such as Transport Layer Security (TLS) for TCP and HyperText Transfer Protocol Secure (HTTPS). This security control protects the confidentiality, integrity and authenticity of communications.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Prioritise modern and secure cipher suites over weak or deprecated cipher suites.
For TLS, utilise the following TLS 1.3 cipher suites ordered by strength:
• TLS_AES_256_GCM_SHA384
• TLS_AES_128_GCM_SHA256
• TLS_AES_128_CCM_SHA256
For HTTPS, implement the following best practices:
• Enforce HTTPS by default – Utilise native attributes or functions provided by operating systems to prevent an app from regressing to HTTP due to changes in URLs made by external sources. This enforces HTTPS by default and prevents accidental unencrypted connections via HTTP. These attributes or functions can be enabled in the configuration file without modifying the app code. Android has required all Android apps to have an HTTPS connection, starting from the 6th of August 2018, via the release of Android 9. Ensure that this is upheld when configuring the app. For Android 8.1 or lower, opt out of cleartext support in “res/xml/network_ security_config.xml”.
Apple has required all iOS apps to have HTTPS connections, starting January 1st, 2017, via the App Transport Security or ATS, a feature that debuted in iOS 9. Ensure that this is upheld when configuring the app.
o Mobile App Network Communication, page 59-70.
o Android Network Communication, Testing the TLS Settings, page 243-244,
o iOS Network Communication, Testing the TLS Settings, page 430-431.
• NIST Special Publication 800-52 Revision 2, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (August 2019), section(s) 3.3.1.2.
• Android, Android Security Paper 2023 (October 2023), Network Security, TLS by Default, page 36-37.
• Apple Developer, Documentation, Preventing Insecure Network Connections, https://developer.apple.com/documentation/security/preventing_insecure_network _connections
NETCOM-BP02 NETWORK COMMUNICATION (DATA-IN-TRANSIT)
Implement certificate pinning
DESCRIPTION
The TLS/SSL protocol secures connections between an app and its server using digital certificates to verify the server’s identity. The connection is established if the server’s certificate originates from a trusted Certificate Authority (CA) and is verified against a list of trusted CAs on Android and iOS devices. However, attackers can compromise or spoof trusted CAs to trick apps into accepting invalid certificates, resulting in a rogue connection to an illegitimate source.
Developers should implement certificate pinning by accepting only certificates that the app has been programmed to trust. This security control protects the confidentiality, integrity and authenticity of the app’s communication with the server; and the privacy of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Trust specific certificates – Configure the app to trust a specific “leaf” server’s certificate. Include alternative certificates such as those of intermediate CAs’.
• Pre-load certificates – Pre-load pinned certificates into the app.
ADDITIONAL NOTES
Manage certificate updates and rotations based on an established security policy.
Layer certificate pinning with security controls on Anti-Tampering & Anti-Reversing.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-NETWORK-2.
• MAS Technology Risk Management Guidelines (January 2021), section(s) C.1e.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 4.7 and 4.8.
• Apple Developer, Documentation, Bundle Resources, Information Property List, Data and storage, NSAppTransportSecurity, NSPinnedDomains, https://developer.apple.com/ documentation/bundleresources/information_property_list/nsapptransportsecurity/ nspinneddomains
NETCOM-BP03 NETWORK COMMUNICATION (DATA-IN-TRANSIT)
APIs are integrated into apps in the form of Software Development Kits (SDKs) and endpoints like REST, HTTP and WebSocket, to facilitate communication between apps and other software components. APIs can be classified into first-party APIs, developed by the app’s organisation to access internal services and third-party APIs, provided by external organisations to enable access to external services. Attackers can exploit poorly integrated APIs to exfiltrate data, gain unauthorised access or cause a denial of service.
Developers should integrate APIs securely. This security control protects the availability of the APIs, the authenticity of parties using the APIs and the confidentiality and integrity of sensitive data communicated over APIs.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Enforce access control – Ensure only authenticated users can access APIs with authentication credentials such as API keys, JWT tokens or OAuth tokens. Use short-lived credentials, such as tokens, to prevent misuse of long-lasting credentials like API keys.
• Implement rate limiting – Limit the rate that APIs can be requested to prevent unexpected traffic from overwhelming APIs’ service availability and degrade performance.
• Perform input and output validation – Ensure that incoming and outgoing data adhere to defined formats, types and constraints. This prevents malformed data from compromising the integrity of the app and reduces the risk of unintended data leakage.
• Encrypt data – Encrypt data transmitted over APIs using secure protocols, such as HTTPS, to prevent eavesdropping and tampering by attackers.
ADDITIONAL NOTES
Since APIs are integrated as SDKs, implement controls outlined in CQEM-BP03.
When integrating first-party API endpoints, an API Gateway simplifies security enforcement by providing authentication, rate limiting, logging and monitoring. However, it can risk being a potential single point of failure.
REFERENCES
This security control is referenced from the following standards:
• MAS Technology Risk Management Guidelines (January 2021), section(s) 6.4.4, 6.4.5 and 6.4.8.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 5.2 and 5.7.
Details of security best practices are referenced from the following documents:
• OWASP API Security Top 10, OWASP Top 10 API Security Risks – 2023, https://owasp.org/API-Security/editions/2023/en/0x11-t10/,
Apps which handle sensitive data on portable devices can be constantly connected to the Internet. Attackers can obtain sensitive data stored or communicated on these devices through physical or digital access. Attackers can also compromise weak cryptographic algorithms to steal sensitive data.
Controls in cryptography ensure the confidentiality, integrity, authenticity and non-repudiation of data used by the app. This involves using strong cryptographic algorithms and securely managing cryptographic keys.
A cryptographic hash algorithm has special properties that map an arbitrary binary string to a binary string with a fixed size of n bits. These algorithms have many information-security applications such as digital signatures, Message Authentication Codes (MAC), authentication, index data in hash tables, fingerprinting, detection of duplicate data and checksums. Attackers compromise weak hash algorithms using collision attacks, pre-image attacks and second pre-image attacks to bypass tampering detection.
Developers should implement strong cryptographic hash algorithms to ensure that the hashes produced are resistant to cryptographic attacks. This security control protects the integrity of the app’s data.
IMPLEMENTATION GUIDANCE
Implement strong cryptographic hash algorithms, such as the following from the Secure Hash Algorithm (SHA) family:
• SHA3-512,
• SHA3-384,
• SHA3-256,
• SHA2-512,
• SHA2-512/256,
• SHA2-384, or
• SHA2-256.
ADDITIONAL NOTES
Utilise only secure cryptographic libraries that are evaluated and secured.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-CRYPTO-1.
• MAS Technology Risk Management Guidelines (January 2021), section(s) 10.1.2.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Cryptography, page 71-76.
• NIST Special Publication 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths (March 2019), section(s) 9.
Encryption involves the use of a key to convert plaintext into undecipherable data, known as ciphertext. Conversely, decryption restores the plaintext from the ciphertext, given the correct key. Weak encryption algorithms are vulnerable to cryptographic attacks, allowing attackers to derive sensitive data out of supposedly undecipherable ciphertexts. This can lead to data breaches, unauthorised access and data tampering.
Developers should implement strong cryptographic encryption algorithms to ensure that encrypted information remains secure and resistant to attacks. This security control protects the confidentiality of app data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Implement strong symmetric key encryption algorithms (CRYPTO-BP02a). Symmetric key algorithms use a single secret key, making them fast and efficient for encrypting and decrypting large amounts of data. However, secure key exchange is required to ensure the trusted distribution of secret keys between authorised parties. Refer to CRYPTO-BP04a for more details about strong key exchange algorithms.
• Implement strong asymmetric key encryption algorithms (CRYPTO-BP02b). Asymmetric key algorithms use a pair of public and private keys to ensure confidentiality, where the public key is used to encrypt data, and the private key is used to decrypt data. The use of asymmetric keys also simplifies key distribution, but they are slower and less efficient for encrypting large amounts of data. Hence, they are often used to encrypt cryptographic keys used for symmetric key encryption.
ADDITIONAL NOTES
The strength of an encryption algorithm can be evaluated by its security bit strength, which estimates the cost for an attacker to break the algorithm. Use cryptographic encryption algorithms that provide at least 128 bits of security.
Additionally, manage keys used in these encryption algorithms based on security best practices. Refer to CRYPTO-BP04 for more information on key management recommendations.
CRYPTO-BP02a
Implement strong symmetric-key encryption algorithms with strong modes of operation
DESCRIPTION
A symmetric key algorithm relies on a single key for encryption and decryption of information. This means both the sender and receiver have a pre-shared secret key utilised to convert the plaintext into ciphertext and vice versa. Attackers perform brute force attacks to guess the key used or use cryptographic attacks to reveal patterns in the ciphertext to deduce the key or plaintext.
Developers should implement strong symmetric key algorithms. This security control protects the confidentiality and integrity of the app’s encrypted data.
IMPLEMENTATION GUIDANCE
Implement strong symmetric key encryption algorithms, such as the following from the Advanced Encryption Standard (AES) family:
• AES-256,
• AES-192, or
• AES-128.
When using AES, implement best practices, such as the following:
• Use strong modes of operation – Strong modes of operation can also ensure the integrity of data, such as the Galois/Counter Mode (GCM). Refer to NETCOM-BP01 for recommended AES modes of operation with TLS.
ADDITIONAL NOTES
Establish and share symmetric encryption keys securely. Refer to CRYPTO-BP03a for more information about implementing secure key exchange algorithms.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-CRYPTO-1.
• MAS Technology Risk Management Guidelines (January 2021), section(s) 10.1.2.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 4.5.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
• NIST Special Publication 800-175B Revision 1, Guideline for Using Cryptographic Standards in Federal Government: Cryptographic Mechanisms (March 2020), section(s) 3.2.
• FIPS 197, Advanced Encryption Standard (AES) (May 2023), section(s) 6.5.
An asymmetric key algorithm relies on a system that uses pairs or related keys, a public key to encrypt and a corresponding private key to decrypt. The private key will be kept secret while the public key can be distributed. However, if weak or deprecated algorithms are used, attackers can exploit known vulnerabilities to discover the private key used or plaintext.
Developers should implement strong asymmetric-key encryption algorithms. This security control protects the confidentiality of the app’s encrypted data.
IMPLEMENTATION GUIDANCE
For Elliptic Curve Cryptography (ECC), implement best practices, such as the following:
• Select secure curves – Select standardised and well-vetted elliptic curves with known security properties. Avoid using custom or non-standard curves to mitigate the risk of vulnerabilities. Use secure elliptic curves, such as the following:
• P-521,
• P-384,
• P-256,
• Curve25519, or
• Curve448.
For Rivest-Shamir-Adleman (RSA) encryption, implement best practices, such as the following:
• Utilise RSA public key encryption keys of at least 3072 bits.
ADDITIONAL NOTES
Consider implementing post-quantum cryptographic algorithms that can be resistant to cryptanalytic attacks by a quantum computer.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-CRYPTO-1.
• MAS Technology Risk Management Guidelines (January 2021), section(s) 10.1.2.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Cryptography, page 71-76.
• NIST Special Publication 800-175B Revision 1, Guideline for Using Cryptographic Standards in Federal Government: Cryptographic Mechanisms (March 2020), section(s) 3.3.
CRYPTO-BP03
Implement strong digital signature algorithms
DESCRIPTION
Digital signature algorithms are specific applications of hash algorithms and asymmetric-key algorithms. With a given message and its hash, a sender can use their private key to generate a signature. Correspondingly, a recipient possessing the message and the sender’s public key can then verify the signature. However, if weak algorithms are used, attackers may tamper with data, forge documents and deny legitimate transactions.
Developers should implement strong digital signatures to sign data and documents sent over their app. Data that can be signed include financial transactions and messages in apps that implement chat functions. Documents that can be signed include legal contracts, financial documents and healthcare records. This security control protects the integrity, authenticity and non-repudiation of the data transmitted by the app, providing users with confidence that the transmitted data is untampered and legitimate.
IMPLEMENTATION GUIDANCE
When using the Elliptic Curve Cryptography Digital Signature Algorithm (ECDSA), implement secure curves, such as the following:
• secp521r1 (P-521),
• secp384r1 (P-384),
• secp256r1 (P-256),
• brainpoolP512r1,
• brainpoolP384r1,
• brainpoolP320r1, or
• brainpoolP256r1.
When using the RSA Probabilistic Signature Scheme (RSA-PSS), implement best practices, such as the following:
• Utilise RSA Digital Signature Algorithm keys of at least 3072 bits.
ADDITIONAL NOTES
Consider implementing post-quantum cryptographic algorithms that can be resistant against cryptographic attacks by a quantum computer.
CRYPTO-BP04
Perform key management based on industry best practices
DESCRIPTION
Cryptographic keys are used in many cryptographic operations such as encryption and digital signatures. However, improper handling of secret keys allows attackers to break the algorithm used and decrypt encrypted data. This allows attackers to obtain sensitive data, tamper with data and forge digital signatures.
Developers should perform key management based on industry best practices to protect the app’s cryptographic keys. Key management covers the management of cryptographic keys throughout their lifecycle, including generation, distribution, storage, archival and deletion. This security control protects the confidentiality, integrity and authenticity of app data; and the security and resilience of cryptographic algorithms that apps utilise.
IMPLEMENTATION GUIDANCE
For key generation, implement best practices, such as the following:
• Generate keys using secure cryptographic modules instead of stable features of the device, such as the device’s IMEI, MAC address, phone number or other hardware identifiers,
• Use a single key for only one purpose, such as encryption, authentication, key wrapping, random number generation or digital signatures,
• Individualise keys by app instance and not by app build, and
• Secure or delete domain parameters used to generate the keys, such as primes p and q in RSA, after use.
For key distribution, implement best practices, such as the following:
• Transport keys using secure channels,
• Import keys only from safe locations,
• When using the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) protocol with both Transport Layer Security (TLS) and Internet Key Exchange (IKE), implement secure curves, such as the following:
o secp521r1 (P-521),
o secp384r1 (P-384),
o secp256r1 (P-256),
o brainpoolP512r1,
o brainpoolP384r1,
o brainpoolP320r1, or
o brainpoolP256r1.
• When using the Finite Field Diffie-Hellman Ephemeral (FFDHE) protocol with TLS, implement secure groups, such as the following:
o ffdhe8192 (ID = 260),
o ffdhe6144 (ID = 259),
o ffdhe4096 (ID = 258), or
o ffdhe3072 (ID = 257).
• When using the Finite Field Diffie-Hellman (FFDH) protocol with IKEv2, implement secure groups, such as the following:
o MODP-8192 (ID=18),
o MODP-6144 (ID=17),
o MODP-4096 (ID=16), or
o MODP-3072 (ID=15).
For key storage, implement best practices, such as the following:
• Never store keys in plaintext format,
• Never hardcode keys,
• Never hide keys in app code by use of lower-level languages such as C or C++,
• Store and process keys in secure cryptographic mechanisms such as Hardware Security Modules or Secure Key Vaults, and
• Apply integrity protections, such as algorithms that support encryption and Message Code Authentication (MAC), on keys while in storage.
For key archival and deletion, implement best practices, such as the following:
• Define a suitable cryptoperiod, which is the duration where a specific key is authorised for use by legitimate entities or will remain in effect, should be defined for each key,
• Change or rotate keys:
o If a previous key is, or is suspected to be, compromised,
o If the key’s cryptoperiod has elapsed,
o If the key has been used to encrypt a specific amount of data, or
o If there is a significant change to the security provided by the algorithm, and
• Destroy keys as soon as they are no longer needed.
ADDITIONAL NOTES
Furthermore, implement operational key management controls such as the following:
• Track cryptographic keys in use through an inventory,
• Enforce least privilege access controls and segregation of duties to restrict unauthorised access to cryptographic keys, and
• Conduct regular audits of key management processes.
Additionally, a key exchange protocol that provides Perfect Forward Secrecy (PFS) ensures that each session key is ephemeral and is not derived from the long-term key. This means that even if a long-term private key used for encryption is compromised, past communications remain secure because each session key is ephemeral and not derived from the long-term key.
PFS adds a layer of security by limiting the potential impact of a key compromise and enhancing the confidentiality and integrity of communication channels. Additionally, employing TLS with mutual authentication for data transmission is essential for ensuring the confidentiality, integrity and authentication of communication channels.
Lastly, consider implementing post-quantum cryptographic algorithms for key distribution that can be resistant against cryptographic attacks by a quantum computer.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-CRYPTO-2.
• NIST Special Publication 800-56A Revision 3, Recommendation for Pair-Wise Key-Establishment Schemes using Discrete Logarithm Cryptography (April 2018), section(s) D.
• NIST Special Publication 800-57 Part 1 Revision 5, Recommendation for Key Management: Part 1 –General (May 2020), section(s) 5.1.2, 5.2 and 5.3.
• NIST SP 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths (March 2019), section(s) 5 and 6.
• NIST Special Publication 800-133 Revision 2, Recommendation for Cryptographic Key Generation (June 2020), section(s) 3.2.
• NIST Special Publication 800-186, Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters (February 2023), section(s) 3.1.2 and H.1.
• IETF, RFC 7919, Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) (August 2016), section(s) 8.8.
• IETF, RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3 (August 2018).
ADDITIONAL RESOURCES
Refer to the following resources for additional guidance:
• FIPS Publication 140-3, Security Requirements for Cryptographic Modules (March 2019).
• FIPS Publication 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (August 2024).
• Apple Developer, Documentation, Security, Certificate, Key, and Trust Services, Keys, https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys.
• NIAP, Mobile Device Fundamentals v3.3 (September 2022).
& EXPLOIT MITIGATIONS
Apps often rely on various external components, including the operating system, software libraries, device memory and different data entry points. However, these components can introduce multiple attack vectors that can lead to unauthorised access, manipulation of app behaviour or the exfiltration of sensitive data.
Controls in code quality and exploit mitigations ensure the integrity and availability of the app and its processes, as well as the confidentiality and privacy of sensitive data. This includes ensuring that updated versions of the app run on secure operating systems versions, managing software dependencies and identifying and addressing code vulnerabilities during development.
ID CONTROL
CQEM-BP01 Check that the device is not operating on known insecure mobile Operating System (OS) versions.
CQEM-BP02 Implement mechanisms to enforce app security updates.
CQEM-BP04 Validate and sanitise all input and output data.
CQEM-BP05 Implement proper error handling.
CQEM-BP06 Implement proper memory management and check for memory corruption bugs.
CQEM-BP01 CODE QUALITY & EXPLOIT MITIGATIONS
Check that the device is not operating on known insecure mobile Operating System (OS) versions
DESCRIPTION
Known insecure mobile OS versions are versions that have explicitly been deemed deprecated by manufacturers and are deemed as containing known vulnerabilities. Allowing an app to run on known insecure OS versions leaves it vulnerable to publicly known threats. This increases the potential for the app to be exploited by known security vulnerabilities.
Developers should check the OS version of the device on which their app is operating. If the device is running on a known insecure OS version and a security patch is available, developers should disable the app. This control security protects the integrity of the app and the confidentiality and privacy of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Check for the OS version of the device,
• Disable the app if the OS version is known to be insecure and has a security patch available,
• Alert and inform users when they are using an insecure OS version, and
• Recommend that users upgrade to the latest version with the latest security patches and protections.
For Android devices, implement best practices, such as the following:
• Set the “<uses-sdk>” attribute – Set the attribute in the app manifest to filter the app from devices not meeting the platform version requirements. This attribute expresses an app’s compatibility with one or more Android OS versions through an API-level integer. This means it does not check the OS version but rather the API level tagged to the OS version. For example, Android 14 is tagged to API level 34. Use the following syntax in the app manifest:
<uses-sdkandroid:minSdkVersion=”integer”
android:targetSdkVersion=”integer”
android:maxSdkVersion=”integer”/>
For iOS devices, implement best practices, such as the following:
• Set the “Deployment Target” – Set the target in the code manifest or project file specifying the earliest operating system version that can run the app. This setting determines the versions that can be used for the app’s operation. For example, if the deployment target is set to iOS 16.0, any device running iOS 16.0 or later can run the app.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-CODE-1.
Details of security best practices are referenced from the following documents:
• Apple Developer, App Dev Tutorials, Adopting new API features, https://developer.apple.com/tutorials/app-dev-training/adopting-new-api-features
CQEM-BP02 CODE QUALITY & EXPLOIT MITIGATIONS
Implement mechanisms to enforce app security updates
DESCRIPTION
Apps regularly release security patches to fix bugs and vulnerabilities identified. Unpatched apps remain vulnerable to these issues, allowing attackers to exploit them to compromise app behaviour or steal sensitive data.
Developers should require users to update their apps to the latest secure version available on official app stores, ensuring that all users are protected against critical vulnerabilities identified in previous app versions. This enforcement can be achieved through various mechanisms, such as app store policies, server-side checks or in-app prompts. This control security protects the integrity of the app processes and the confidentiality and privacy of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
1. Retrieve the current app version – Obtain the current version of the app on the user’s device. This can be found in the “BuildConfig” class for Android or the “Info.plist” file for iOS.
2. Check the latest secure version from a web or app server – Implement a mechanism within the app to check the latest secure version from the web or app server upon runtime. For example, use an API or a version check endpoint to retrieve the latest secure version number, with the latest secure app version updated on the web or app server. Alternatively, developers can fetch the latest secure version numbers from Google Play Store APIs or App Store APIs.
3. Compare versions and prompt the user to update – Once the latest secure version is known or retrieved, compare it to the current app version If the current app version is outdated, prompt the user to update the app and provide a button that directs them to the default app store for updating. For Android devices, also implement the check and prompt using the ‘in-app updates’ feature on Google Play, available on devices running Android 5 and above. Note that this feature is supported only on Android devices, tablets and ChromeOS devices. Refer to the Android Developer Guide for more information.
4. Disable app versions with known vulnerabilities – If the user chooses not to update the app, disable the app and inform the user via a prompt that the app will remain disabled until the security update is applied.
ADDITIONAL NOTES
Encourage users to enable “Auto-update apps” for the Google Play Store and “App Updates” for the iOS App Store. However, there are currently no native solutions in Android and iOS to perform automatic app updates for users who do not enable this setting.
Establish a guideline to distinguish between urgent security-related updates and non-urgent product feature updates before implementing the updates. Security-related updates should be prioritised to minimise the risk of introducing new vulnerabilities into the apps.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-CODE-2.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 9.1.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Code Quality and Build Settings, Testing Enforced Updating, page 297-298,
o iOS Platform APIs, Testing Enforced Updating, page 502-503.
Software dependencies refer to pre-written code, such as libraries, frameworks and modules, that are integrated into an app to provide specific functionalities or streamline development. These dependencies, which can be platform-specific or from third-party sources, offer readymade tools that speed up development. However, while they provide useful features, they can also introduce supply chain vulnerabilities by incorporating potentially vulnerable code into the app. Security vulnerabilities such as outdated code, unpatched flaws or improper implementation can be exploited by threat actors.
Developers should regularly inspect software dependencies to reduce the likelihood of exploitation and safeguard the app from common cybersecurity threats. This security control protects the confidentiality and integrity of the app, ensuring that only secure and trusted code is integrated.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Evaluate dependency necessity – Carefully evaluate and review whether a software dependency is essential for the app’s functionality. If a dependency is necessary, import only the relevant parts of the library to minimise the number of external dependencies and reduce the attack surface. These decisions should be guided by an organisational security policy that governs the identification and management of dependencies.
• Vet before integration – Conduct thorough security assessments before integrating any third-party library or component. This includes checking for known vulnerabilities, reviewing the source code if possible and evaluating the reputation of the library.
• Use automated dependency management – Use a reliable package manager to handle dependencies. These managers help to regularly monitor and keep dependencies up to date with the latest security patches and releases.
• Conduct dependency security analysis – Use Software Composition Analysis (SCA) tools that will automatically analyse dependencies and identify security vulnerabilities. Static Application Security Testing (SAST) tools and Dynamic Application Security Testing (DAST) tools can also identify vulnerabilities from insecure or unnecessary dependencies.
• Implement dependency-specific best practices – Implement best practices for platform-specific dependencies in CQEM-BP03a and third-party dependencies in CQEM-BP03b.
ADDITIONAL NOTES
Practice DevSecOps in the development process to reduce vulnerabilities and blind spots when including software dependencies.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-CODE-3.
• MAS Technology Risk Management Guidelines (January 2021), section(s) 6.1.3.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 6.
Details of security best practices are referenced from the following documents:
• OWASP Software Assurance Maturity Model v2.0 (January 2020), Implementation, Stream B –Software Dependencies, page 149-157.
• NIST Special Publication 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities (February 2022), sections 2.PW4, 2.PW5, 2.PW6, 2.PW7 and 2.PW8.
CQEM-BP03a CODE QUALITY & EXPLOIT MITIGATIONS
Implement secure platform-specific dependencies
DESCRIPTION
Platform-specific dependencies for mobile platforms refer to software libraries, frameworks or components that are specific to a particular mobile operating system. These dependencies can be integrated with native functionalities and can optimise app performance for a specific platform. While platform-specific dependencies offer useful features and speed up development by providing pre-built tools, they can introduce security vulnerabilities if they are not kept up to date.
Developers should keep platform-specific dependencies updated and ensure that they are implemented securely. This security control protects the integrity of the app and its processes.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Use native IDEs – Use native Integrated Development Environments (IDEs), such as Android Studio for Android apps and Xcode for iOS apps, to verify that the app does not contain vulnerable or deprecated platform-specific dependencies. Utilise these IDEs to upgrade or migrate to other secure platform-specific dependencies provided by the device OS provider.
• Use IDE’s built-in features and tools – Use native IDEs’ built-in security features and tools to secure the app. Configure the IDE with secure settings and enable security features such as code signing, encryption and secure communication. Use tools available in native IDEs to perform debugging and code reviews to identify and patch potential vulnerabilities. However, developers should also be cautious against granting excessive permissions to these IDE plugins and tools.
• Use platform-specific tools – Use platform-specific tools that can analyse and review platform-specific dependencies, as explained in CQEM-BP03. These include SCA, SAST and DAST tools. Platform-specific linters also detect any potential vulnerabilities.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-CODE-3.
Details of security best practices are referenced from the following documents:
• OWASP Software Assurance Maturity Model v2.0 (January 2020), Implementation, Stream B –Software Dependencies, page 149-157.
• NIST Special Publication 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities (February 2022), sections 2.PW4, 2.PW5, 2.PW6, 2.PW7 and 2.PW8.
CQEM-BP03b CODE QUALITY & EXPLOIT MITIGATIONS
Implement secure third-party dependencies
DESCRIPTION
Third-party dependencies refer to external libraries, frameworks or components provided by thirdparty vendors or open-source communities that developers integrate into an app. However, while they provide useful features, they can also introduce supply chain vulnerabilities by incorporating potentially vulnerable code into the app. Security vulnerabilities such as outdated code, unpatched flaws or improper implementation can be exploited by threat actors.
Developers should keep third-party dependencies updated and regularly monitor for security patches released by dependency sources. This includes verifying the integrity of dependencies to ensure that the app only imports untampered dependencies. This security control protects the integrity of the app and its processes.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Use actively maintained dependencies – Actively maintained dependencies are more likely to offer long-term support, reducing the risk of encountering compatibility issues or being left unpatched.
• Use mature dependencies with versioning strategies – Mature dependencies with clear versioning strategies are less likely to undergo major breaking changes, making upgrades and maintenance more straightforward and reducing the risk of unexpected issues.
• Utilise tools to assist in keeping track of dependencies – Use a Software Bill Of Materials (SBOM) to enhance the security of third-party dependencies that the app uses. An SBOM provides visibility, enables risk management, promotes supply chain security, facilitates compliance management, offers remediation guidance and supports continuous monitoring efforts for the development team.
• Consider dependency reputation - Incorporate the reputation of dependencies as a consideration to determine their security. Relevant factors that indicate reputation include:
o Open-Source Repository – Using dependencies from open-source repositories, such as GitHub, indicates a higher level of security, as these platforms often have measures in place to detect and mitigate malicious code. In addition, being part of a well-known repository increases the likelihood of community oversight, leading to quicker detection and resolution of security issues.
o Popularity – Using dependencies with a large user base can lead to better community support and faster responses to issues. Furthermore, popular libraries are more likely to be compatible with other tools and frameworks, making integration into existing projects smoother. Using dependencies that are maintained by big communities often have more resources for development and support, while those maintained by a single developer may not.
• Conduct continuous assessments – Conduct continuous assessments and manual reviews to maintain vigilance over potential vulnerabilities. Software Composition Analysis tools can be used by small development teams to evaluate third-party dependencies and reduce the risk of including malicious or vulnerable code.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-CODE-3.
• MAS Technology Risk Management Guidelines (January 2021), section(s) 6.1.3 and 6.1.4.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 6.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Code Quality and Build Settings, Checking for Weaknesses in Third Party Libraries, page 298-299,
o iOS Platform APIs, Checking for Weaknesses in Third Party Libraries, page 503-516.
• OWASP Software Assurance Maturity Model v2.0 (January 2020), Implementation, Stream B –Software Dependencies, page 149-157.
• NIST Special Publication 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities (February 2022), sections 2.PW4, 2.PW5, 2.PW6, 2.PW7 and 2.PW8.
ADDITIONAL RESOURCES
Refer to the following resources for additional guidance:
• Google Support, Play Console Help, Help Center, Policy Center, SDK Requirements, https://support.google.com/googleplay/android-developer/answer/13323374#zippy=
• Apple Developer, Support, Upcoming third-party SDK requirements, https://developer.apple.com/support/third-party-SDK-requirements
DESCRIPTION
Validate and sanitise all input and output data
Apps handle a significant amount of data, including data going to or coming from untrusted sources such as external entities, app servers or users. Attackers can exploit this input to perform injection attacks, such as SQL injection, which allows them to manipulate data, steal sensitive data or compromise the system. Additionally, manipulating displayed data can lead to Cross-Site Scripting (XSS) attacks that exploit presentation vulnerabilities to inject and execute malicious code or expose sensitive data.
Developers should validate and sanitise all untrusted input and output data to ensure that only expected data is processed and displayed. This security control protects the integrity of the app’s processes and the privacy of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Validate and sanitise all input and output data at both the client-side and server-side to ensure that data transferred between the app and the server always remains valid and non-malicious.
For data validation, implement best practices, such as the following:
• Validate all input regardless of source – Validate all input data as early as possible regardless of source. These include, but are not limited to, form fields, file uploads, API requests and API responses.
• Implement a “fail-fast” approach – Reject incorrect input is rejected as early as possible before it can cause further harm as it propagates through the system.
• Implement allowlist validation – Acceptance of only defined valid input values or patterns and rejection of anything else that does not match the predefined criteria helps to mitigate the risk of security vulnerabilities arising from unexpected or malicious input. Accepted inputs are defined using an allowlist with syntactic and semantic rules.
To implement syntactic rules, accept only input that conforms to the expected format. The following includes, but are not limited to:
o Allow only alphanumeric characters in a username, and
o Allow only email addresses that follow valid formats such as “example@gmail.com”,
To implement semantic rules, accept only input that is within an acceptable range for the given business logic. The following includes, but are not limited to:
o Allow only birth dates that are in the past,
o Allow only non-negative product prices, and
o Allow only shipping addresses that match the selected country.
• Use input validation tools – Use the input validation tools, such as the following:
o Input validation libraries/frameworks, such as OWASP ESAPI, Apache Common Validator, Spring Validation and jQuery Validation Plugin,
o Regular Expression (RegEx) Testers, such as Regex 101 and RegExr,
o Integrated Development Environments, such as Visual Studio, Eclipse, JetBrains and IntelliJ IDEA,
o Static Application Security Testing (SAST) tools, such as GitHub code scanning and AppSweep, and
o Dynamic Application Security Testing (DAST) tools, such as QARK.
For data sanitisation, implement best practices, such as the following:
• Escape free-form text –When free-form text is required, escape user input by treating inputs literally, using built-in functions or libraries available in common programming languages, such as JavaScript, PHP, Java and Python, to prevent unexpected behaviour.
• Check uploaded files –When file upload is required, check uploaded files for malicious content by using in-house virus scanners or third-party virus scanners such as VirusTotal API or MetaDefender API.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-CODE-4.
• MAS Technology Risk Management Guidelines (January 2021), section(s) 6.1.2.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 10 and 12.12.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Code Quality and Build Settings, Testing Local Storage for Input Validation, page 291292.
DESCRIPTION
CQEM-BP05 CODE QUALITY & EXPLOIT MITIGATIONS
Implement proper error handling
Apps often encounter scenarios not are not originally anticipated, resulting in errors and exceptions. These errors can cause the app to crash, produce unexpected behaviours or disclose sensitive data. Attackers can exploit these vulnerabilities to launch Denial-Of-Service (DoS) attacks or gain access to sensitive data.
Developers should implement proper error handling to manage unexpected or erroneous situations and prevent the app from crashing or behaving unpredictably. This security control protects the integrity of the app’s processes and the privacy of sensitive data.
IMPLEMENTATION GUIDANCE
For exception handling, implement best practices, such as the following:
• Identify errors – Identify potential errors that may arise during program execution. This includes runtime errors, accessing invalid memory locations or encountering unexpected input.
• Utilise exception handling mechanisms – Utilise exception handling mechanisms, such as try-catch blocks, to gracefully intercept, handle and recover from exceptions.
• Degrade functionalities gracefully – Degrade functionalities gracefully when errors cannot be avoided. This involves implementing fallback mechanisms, alternative pathways or default values to prevent catastrophic failures.
• Use exception handling tools – Use exception handling tools, such as the following:
o Static Application Security Testing (SAST) – SAST solutions can identify potential security issues by analysing the code statically, such that it can catch issues such as buffer overflows, injection vulnerabilities, insecure coding practices and other common security flaws.
o Dynamic Application Security Testing (DAST) – DAST solutions can identify potential security issues dynamically by providing insights into how the app behaves in real-world scenarios.
o Integrated Development Environments (IDE) – IDEs have features that allow for the detection of errors within code and support for error handling. These features include syntax highlighting, integration with linters, debugging tools and autocomplete suggestions. Developers should use these tools to complement their identification and management of errors.
For error message handling, implement best practices, such as the following:
• Use generic error messages – Generic messages prevent the exposure of sensitive data. For example, “Login failed. Please check your credentials and try again.” This example is more generic and does not reveal whether the username or password was incorrect.
• Custom error pages – Custom error messages avoid disclosing sensitive data to minimise the app’s attack surface area. Remove displays of sensitive data instead of displaying error information such as HTTP status codes, app exceptions and error message content. Avoiding the disclosure of sensitive data will minimise the app’s attack surface area.
• Perform risk assessments – Perform risk assessments for error messages that require sensitive data. Additionally, sanitise these error messages by truncating or masking sensitive data. For example, “Your credit card number ending in ****3456 could not be validated.” This example gives users enough information to recognise their credit card without exposing the full credit card number.
For debugging and logging errors, implement best practices, such as the following:
• Use logging frameworks – Logging frameworks categorise different events within the app based on their severity or urgency, such as FATAL, INFO and DEBUG, to identify, prioritise and address critical issues. For example, log an event that leads to the disclosure of sensitive data, it would be appropriate to log it at the “FATAL” level. Immediately alert the responsible teams upon the logging of “FATAL” logs, to ensure a timely and prompt response to the event.
• Disable logging in release builds – Use macros or debug-state-related guards to disable logging in the release build of the app. For example, debug-only code should be wrapped in if-blocks conditional on a debug flag, to ensure that the debug statements are never compiled in the app’s release version.
• Perform risk assessments – Perform cases where these error messages require sensitive data. Store these error messages should be stored in a separate logging system configured with stricter access control. Additionally, sanitise the error messages by truncating or masking sensitive data. For example, “2024-03-21 08:55:23,200 – DEBUG – User provided credit card number: ****3456.” This example provides developers with enough information to understand the sequence of events leading to an issue without exposing the full credit card number.
REFERENCES
This security control is referenced from the following standards:
• MAS Technology Risk Management Guidelines (January 2021), section(s) 6.1.2.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 1.33, 2.4 and 10.3.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Anti-Reversing Defenses, Testing for Debugging Symbols, page 321,
o Android Anti-Reversing Defenses, Testing for Debugging Code and Verbose Error Logging, page 321-322,
o iOS Platform APIs, Testing for Debugging Code and Verbose Error Logging, page 516-518.
Refer to the following resources for additional guidance:
• Swift, Documentation, The Swift Programming Language (6 beta), Error Handling, https://docs.swift.org/swift-book/documentation/the-swift-programming-language /errorhandling
CQEM-BP06 CODE QUALITY & EXPLOIT MITIGATIONS
Implement proper memory management and check for memory corruption bugs
DESCRIPTION
Apps require access to device memory for the execution of their functionalities. However, memory corruption bugs and vulnerabilities primarily occur from programming errors that cause the app to access an unintended memory location and potentially bypass kernel memory protections. Attackers capitalise on these memory vulnerabilities to hijack the app’s execution flow, execute malicious code and extract sensitive data.
Developers should ensure that the app has properly coded memory management and does not contain memory corruption bugs. This security control protects the integrity of the app’s process and the confidentiality of sensitive data.
IMPLEMENTATION GUIDANCE
For memory management, implement best practices, such as the following:
• Randomise or obfuscate memory locations used – Implement Address Space Layout Randomisation (ASLR) which is a technique for randomising the app’s usage of the OS’s memory space. Android began using ASLR in Version 4.0 in 2011 and iOS began using ASLR in iOS 4.3 in 2011.
• Use programming languages with secure memory abstractions – Use programming languages that provide appropriate memory abstractions, such as Java, C#, Python and JavaScript. Conversely, C, Objective-C and C++ are manual memory management programming languages which expose memory vulnerability. Android development is primarily done in Java, which is inherently safe from memory corruption. However, native apps using JNI libraries may be susceptible. Similarly, iOS apps can wrap C/C++ calls in Objective-C or Swift, making them susceptible as well.
• Compile apps securely – Use compiler options that introduce protections against memoryrelated attacks, such as Return Oriented Programming (ROP) attacks. For example, the use of “-fstack-protector-all” enables stack canaries that detect modifications to the stack, such as in a buffer overflow attack.
For memory corruption bugs or vulnerabilities detection, implement best practices, such as the following:
• Perform input fuzzing – Fuzzing is where malformed or unexpected inputs are intentionally sent to a software program to identify input validation flaws that could lead to security vulnerabilities, such as buffer overflows.
• Manage pointers securely – Free all pointers to deleted or deallocated objects and null all freed pointers. This prevents dangling pointers, where an object is deleted or deallocated, but the pointer that points to that object still exists. Attackers can utilise dangling pointers to read or write object variables or other memory structures.
• Format strings securely – Pass all format string functions as a static string and use functions that do not support the “%n” operator in format strings. This prevents format string vulnerabilities where user input is passed to the format string parameter of the “printf” family of C functions. Malicious attackers can manipulate inputs to inject format tokens such as “%c” and “%n” to access memory in the app.
• Perform Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) – SAST and DAST are two different approaches to security testing that can help detect and prevent memory problems in apps, including buffer overflow and related vulnerabilities.SAST tools analyse the app’s codebase for known security vulnerabilities, including memory-related issues. By examining the code structure, data flows and control flows, SAST tools can help detect and prevent memory bugs and improper memory management in apps. DAST tools can detect memory-related vulnerabilities such as buffer overflows by automating input fuzzing and sending specially crafted inputs that may trigger memory vulnerabilities in the app.
ADDITIONAL NOTES
Swift is a programming language that automatically manages memory and is less prone to memory leaks, buffer overflows and other memory-related vulnerabilities. However, Swift also offers some mechanisms for manual memory management intended for advanced use cases and should be used with caution.
Additionally, native IDEs, such as Android SDK and Xcode, can help to correct common memorycorruption errors such as buffer overflows. For example, use Xcode’s Debug Memory Graph feature and configure the building settings reference “CLANG_ANALYZER_MEMORY_MANAGEMENT” to catch memory-related vulnerabilities.
REFERENCES
This security control is referenced from the following standards:
• MAS Technology Risk Management Guidelines (January 2021), section(s) 6.1.2.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 3.4, 11.2 and 12.13.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Mobile App Code Quality, Memory Corruption Bugs, page 80-83,
o iOS Platform APIs, Testing Enforced Updating, page 502-503.
• NIST Special Publication 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities (February 2022), sections 2.PW6.
ADDITIONAL RESOURCES
Refer to the following resources for additional guidance:
• Apple Developer, Documentation, Xcode, Performance and metrics, Reducing your app’s memory use, https://developer.apple.com/documentation/xcode/reducing-your-app-s-memory-use
• Apple Developer, Documentation Archive, Secure Coding Guide, Types of Security Vulnerabilities, Avoiding Buffer Overflows and Underflows, https://developer.apple.com/library/archive /documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html
• Swift, Documentation, The Swift Programming Language (6 beta), Memory Safety, https://docs .swift.org/swift-book/documentation/the-swift-programming-language/memorysafety/
PLATFORM INTERACTIONS
To maximise apps’ features and functions, apps communicate and interact with the device it is running on, the underlying operating system and platform services. However, attackers can exploit insecure communications and poorly configured services to extract sensitive data, inject malicious code and create unexpected app behaviour.
Controls in platform interactions ensure the integrity of the app’s processes and the privacy of sensitive data. This includes implementing inter-process communication mechanisms, WebViews and input methods securely to improve the overall security of the interactions between the app and the device operating system.
ID CONTROL
PI-BP01 Implement Inter-Process Communication (IPC) mechanisms securely.
PI-BP02 Implement WebViews securely.
PI-BP03 Handle input methods securely.
PI-BP01 PLATFORM INTERACTIONS
Implement Inter-Process Communication (IPC) mechanisms securely
DESCRIPTION
IPC mechanisms are used by apps to allow different processes within the app to communicate and share data efficiently, and to enable features such as memory sharing and background processing. However, malicious attackers can exploit accidental sensitive data disclosure from IPC mechanisms.
Developers should implement IPC mechanisms securely by ensuring secure configurations of components, such as activities, services or content, that can be accessed by other apps. This security control protects the privacy of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Expose only necessary components – Review all components, such as activities, services or content and expose only those necessary for the app’s functionalities.
• Use Static Application Security Testing (SAST) – Use SAST tools, such as the Mobile Security Framework (MobSF), to verify the secure implementation of IPC mechanisms.
For Android devices, implement best practices, such as the following:
• Configure the “AndroidManifest.xml” securely – Remove usages of “android:exported=“true”” or definitions of “<intent-filter>” for components, unless that component needs to be exposed.
• Apply permissions to exposed components – Apply a security policy to exposed components by using the “<permission>” element and setting an “android:protectionLevel” to limit access to the exposed component.
ADDITIONAL NOTES
This security control primarily targets Android devices, since iOS minimises the potential attack surface by limiting IPC options.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-PLATFORM-1.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 1.16.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Platform Overview, Android Application Structure, Communication with the Operating System, page 95-96,
o Android Platform APIs, Testing for Sensitive Functionality Exposure Through IPC, page 269-276,
o Android Platform APIs, Determining Whether Sensitive Stored Data Has Been Exposed via IPC Mechanisms, page 276-280,
o iOS Platform Overview, page 327,
o iOS Platform APIs, Determining Whether Sensitive Data Is Exposed via IPC Mechanisms, page 477-478,
o iOS Platform APIs, Testing for Sensitive Functionality Exposure Through IPC, page 480.
• GitHub, Mobile Security Framework (MobSF), https://github.com/MobSF/Mobile-Security-Framework-MobSF
PI-BP02 PLATFORM INTERACTIONS
Implement WebViews securely
DESCRIPTION
WebViews embed web pages to integrate web content from a web server or a local file directly into the app. This allows users to interact with web content through the app, for functions such as login processes through third-party services or to interactions with rich media content like interactive graphics. However, attackers can perform attacks, such as Cross-Site Scripting (XSS), to exploit vulnerable web content or poorly configured WebViews to inject malicious scripts to compromise user data, alter app behaviour or access sensitive functionalities.
Developers should implement WebViews securely by verifying web content and securely configuring it. This security control protects the integrity of the app processes and the confidentiality of sensitive data.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Avoid deprecated or unsupported libraries and methods – Avoid using deprecated or unsupported libraries and methods, such as Android’s Webkit and iOS UIWebView. This ensures that the app avoids potential issues related to deprecated functionality.
• Utilise safe browsing APIs – Incorporate safe browsing APIs, such as Google Safe Browsing API and Virus Total API, to validate and sanitise insecure parameter inputs. This enhances security by identifying and blocking access to potentially harmful content or malicious URLs.
• Disable content caching – Use server-side headers like “no-cache” to control caching behaviour to prevent the app from storing content locally. This helps to ensure that users always access the latest content from the server and reduces the risk of serving outdated or sensitive data.
• Employ secure protocols – Employ secure protocols to prevent deep link collision to ensure that the app properly handles navigation to specific content without ambiguity or security risks.
• Disable JavaScript – Disable JavaScript to mitigate risks associated with malicious JavaScript execution. However, if JavaScript is necessary for the app to function, implement best practices, such as the following:
o Enforce the use of HTTPS when communicating with endpoints,
o Load JavaScript and HTML from within the local app data directory or trusted web servers only, and
o Disallow users from defining sources that resources are loaded from.
• Verify web content – Check that web content loaded into the WebView is secure against web application threats. If a file upload feature is implemented, check for file inclusion vulnerabilities in the app’s WebView implementation, such as local file inclusion vulnerabilities and remote file inclusion vulnerabilities.
REFERENCES
This security control is referenced from the following standards:
• OWASP Mobile Application Security Verification Standard v2.1.0 (January 2024), MASVS-PLATFORM-2.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 1.34, 12.1, 12.14 and 12.16.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Platform APIs, Testing WebView Protocol Handlers, page 258-259,
o Android Platform APIs, Testing JavaScript Execution in WebViews, page 268-269,
o Android Platform APIs, Testing for Java Objects Exposed Through WebViews, page 285-286,
o Android Code Quality and Build Settings, Testing for URL Loading in WebViews, page 299-300.
o iOS Platform APIs, Testing WebView Protocol Handlers, page 450-454,
o iOS Platform APIs, Determining Whether Native Methods are Exposed Through WebViews, page 474-477.
• Apple Developer, Documentation, WebKit, https://developer.apple.com/documentation/webkit
PI-BP03 PLATFORM INTERACTIONS
Handle input methods securely
DESCRIPTION
Input methods, such as keyboards and clipboards, enable users to enter information into apps, including sensitive data. Attackers perform keylogging attacks, which monitor, log and record keyboard keystrokes without the user’s knowledge and consent. This is usually achieved using malicious third-party keyboards or capturing text in the clipboard.
Developers should handle input methods securely to control the flow of data and minimise the risk of data leakage. This security control protects the privacy of users and safeguards sensitive data against inadvertent loss or misuse.
IMPLEMENTATION GUIDANCE
Implement best practices, such as the following:
• Use secure in-app custom keyboard – Use in-app keyboards to control the environment where sensitive data is entered. This mitigates the risk of insecure third-party virtual keyboards acting as keyloggers to capture keystrokes.
• Restrict input method features – Disable autocorrect, autofill, autosuggestion, cut, copy and paste functionalities for inputs that could expose sensitive data.
ADDITIONAL NOTES
Some examples of functions that should utilise in-app keyboards include but are not limited to, logging in, entering an OTP or other verification factors, etc.
This security control primarily targets Android devices, as the native keyboard of Android devices can be changed and Android does not provide a method by which to enforce the usage of native/ trusted keyboards. This exposes apps to security vulnerabilities as the trusted path between keyboard inputs and apps has untrusted parties between them. Hence, the main goal of this control is to ensure the security of the trusted path.
For Android devices, Google Play also offers the Play Integrity API that verifies the integrity of an app and the Android device that it is running on. Utilise the environment details field to detect other apps on the device with permissions enabled that can be used to capture the inputs and outputs of their app.
REFERENCES
This security control is referenced from the following standards:
• MAS Technology Risk Management Guidelines (January 2021), section(s) C.1f.
• ENISA Smartphone Secure Development Guidelines (December 2016), section(s) 1.19, 1.20 and 1.21.
Details of security best practices are referenced from the following documents:
• OWASP Mobile Application Security Testing Guide v1.7.0 (October 2023),
o Android Data Storage, Overview, User Interface, Keyboard Cache, page 203,
o Android Data Storage, Determining Whether the Keyboard Cache Is Disabled for Text Input Fields, page 214-215,
o iOS Data Storage, Overview, User Interface, Keyboard Cache, page 400,
o iOS Data Storage, Finding Sensitive Data in the Keyboard Cache, page 414-415.
• Android Developers, Google Play, Play Integrity, Integrity verdicts, Environment details field, https://developer.android.com/google/play/integrity/verdicts#environment-details-field
REFERENCES
Android. (October 2023). Android Security Paper 2023. Retrieved from https://blog.google/ products/android-enterprise/android-securitypaper-2023/
Apple Inc. (n.d.). Apple Developer. Retrieved July, 2024, from https://developer.apple.com/
Apple Inc. (May 2024). Apple Platform Security. Retrieved from https://support.apple.com/en-sg/ guide/security/welcome/web
Emerging Technologies, PCI Security Standards Council. (September 2017). PCI Mobile Payment Acceptance Security Guidelines for Developers v2.0. Retrieved from https:// www.pcisecuritystandards.org/documents/ PCI_Mobile_Payment_Acceptance_Security_ Guidelines_for_Developers_v2_0.pdf
European Union Agency For Network And Information Security (ENISA). (December 2016). Smartphone Secure Development Guidelines. Heraklion, Greece. Retrieved from https://www.enisa. europa.eu/publications/smartphone-securedevelopment-guidelines-2016
Google. (n.d.). Android Developers. Retrieved July, 2024, from Android Mobile App Developer Tools: https://developer.android.com/
Internet Engineering Task Force (IETF). (August 2016). RFC 7919, Negotiated Finite Field DiffieHellman Ephemeral Parameters for Transport Layer Security (TLS). Retrieved from https:// datatracker.ietf.org/doc/html/rfc7919
Internet Engineering Task Force (IETF). (August 2018). RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3. Retrieved from https://datatracker.ietf.org/doc/html/rfc8446
Monetary Authority of Singapore (MAS). (January 2021). Technology Risk Management Guidelines. Singapore. Retrieved from https://www.mas. gov.sg/regulation/guidelines/technology-riskmanagement-guidelines
National Institute of Standards and Technology (NIST). (April 2018). NIST Special Publication 800-56A Revision 3, Recommendation for PairWise Key-Establishment Schemes using Discrete Logarithm Cryptography. Retrieved from https:// doi.org/10.6028/NIST.SP.800-56Ar3
National Institute of Standards and Technology (NIST). (August 2019). NIST Special Publication 800-52 Revision 2, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. Retrieved from https://doi.org/10.6028/NIST.SP.800-52r2
National Institute of Standards and Technology (NIST). (February 2022). NIST Special Publication 800218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. Retrieved from https://doi.org/10.6028/NIST. SP.800-218
National Institute of Standards and Technology (NIST). (February 2023). FIPS 186-5, Digital Signature Standard (DSS). Retrieved from https://doi.org/10.6028/NIST.FIPS.186-5
National Institute of Standards and Technology (NIST). (February 2023). NIST Special Publication 800-186, Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters. Retrieved from https://doi. org/10.6028/NIST.SP.800-186
National Institute of Standards and Technology (NIST). (June 2017). NIST Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management. Retrieved from https:// doi.org/10.6028/NIST.SP.800-63b
National Institute of Standards and Technology (NIST). (June 2020). NIST Special Publication 800-133, Recommendation for Cryptographic Key Generation. Retrieved from https://doi. org/10.6028/NIST.SP.800-133r2
National Institute of Standards and Technology (NIST). (March 2019). NIST Special Publication 800-131A Revision 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths. Retrieved from https://doi.org/10.6028/NIST. SP.800-131Ar2
National Institute of Standards and Technology (NIST). (March 2020). NIST Special Publication 800-175B Revision 1, Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms. Retrieved from https://doi.org/10.6028/NIST. SP.800-175Br1
National Institute of Standards and Technology (NIST). (May 2020). NIST Special Publication 800-57 Part 1 Revision 5, Recommendation for Key Management: Part 1 - General. Retrieved from https://doi.org/10.6028/NIST.SP.80057pt1r5
National Institute of Standards and Technology (NIST). (May 2023). FIPS 197, Advanced Encryption Standard (AES). Retrieved from https://doi.org/10.6028/NIST.FIPS.197-upd1
National Institute of Standards and Technology (NIST). (September 2020). NIST Special Publication 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations. Retrieved from https://doi. org/10.6028/NIST.SP.800-53r5
The OWASP Foundation. (January 2020). OWASP Software Assurance Maturity Model v2.0. Retrieved from https://owasp.org/www-projectsamm/
The OWASP Foundation. (January 2024). Mobile Application Security Verification Standard v2.1.0. The OWASP Foundation. Retrieved from https:// mas.owasp.org/MASVS/
The OWASP Foundation. (October 2023). Mobile Application Security Testing Guide v1.7.0. The OWASP Foundation. Retrieved from https://mas. owasp.org/MASTG/
The OWASP Foundation. (n.d.). OWASP API Security Top 10. Retrieved July, 2024, from https://owasp. org/API-Security/
The OWASP Foundation. (n.d.). OWASP Cheat Sheet Series. Retrieved July, 2024, from https:// cheatsheetseries.owasp.org/index.html
The OWASP Foundation. (n.d.). OWASP Controls. Retrieved July, 2024, from https://owasp.org/ www-community/controls/
