Mobile application

security principles
OWASP mobile security
guidelines
• OWASP – Open Worldwide Application Security Project is a
community and foundation that produces freely available articles,
guidelines and documents on improving security in various types of
applications (web, IoT, mobile, desktop)
• Guides on security considerations for mobile applications
development
• https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Se
curity_Cheat_Sheet.html
I. Architecture and design
I. Architecture and design
• Use security principles in the development cycle:
• principle of Least Privilege: users should only be given the minimum amount of
access necessary to perform their job
• principle of Separation of Duties: separate functionality to different roles, don’t
let a regular user with all privileges
• principle of Defense-in-Depth: implement several layers of security (e.g.
physical security, network security, application security, and data security)
• principle of Zero Trust: assumes that all users, devices, and networks are
untrusted and must be verified before access is granted
• principle of Security-in-the-Open: using secure coding practices, testing for
vulnerabilities, and using secure development tools
I. Architecture and design
(cont.)
• secure your APIs usage:
• mobile app communicates securely (encrypted) with backend services
• use OAuth2, JWT or something similar for authentication
• regularly rotate and update any used API keys/tokens
• request only the permissions the mobile app needs, not more
• don’t store application files with maximum permissions
• app should have the most secure setting by default
• ensure third-party libraries used are secure (i.e. library signing, trusted
and validated libraries, library updates, patches
II. Authentication and
authorization
II.1 Zero trust, don’t trust
the user
• perform authorization server-side and only load data on the device after
successful authentication.
• encrypt data stored locally using a key derived from the user’s login
credentials.
• don’t store user passwords on the device; use device-specific tokens that can
be revoked.
• avoid using spoofable values like device identifiers for authentication.
• assume all client-side controls can be bypassed and perform them server-
side as well.
• include mobile code to detect code/binary tampering (refuse to run in
mobile device is rooted)
II.2 Credential handling
• do not hardcode credentials in the mobile app
• encrypt credentials in transmission
• do not store user credentials on the device, use revokable/temporary
tokens
II.3 Passwords, PINs and
biometric authentication
• require password complexity
• do not allow short PINs such as 4 digits
• use platform specific secure storage mechanisms, such as Keychain (iOS) or
Keystore (Android)
• use platform-supported methods for biometric authentication (always
provide a fallback, such as a PIN)
• in the error message for a failed authentication don’t specify the reason
(user unknown, wrong password, wrong email)
• store authentication tokens securely, don’t store passwords locally
• use multifactor authentication
II.4 Session management and
sensitive operations
• sessions should timeout after inactivity
• offer a remote logout feature
• use randomly generated session tokens
• secure session data storage, both client and server side
• require users to re-authenticate before executing sensitive operations
like password change
• consider requiring re-authentication before displaying highly sensitive
information
III. Data storage and privacy
• encrypt sensitive data both at rest and in transit
• store private data on the device's internal storage
• use platform APIs for encryption; do not attempt to implement your
own encryption algorithms
• beware of caching, logging, and background snapshots; ensure that
sensitive data is not leaked through these mechanisms
• minimise any personally identifiable information
III. Data storage and privacy
(continuation)
• Apps handle sensitive data coming from many sources such as the
user, the backend, system services or other apps on the device and
usually need to store it locally
• The storage locations may be private to the app (e.g. its internal
storage) or be public and therefore accessible by the user or other
installed apps (e.g. public folders such as Downloads).
• Sensitive data should be stored securely
III. Data storage and privacy
(continuation)
• Apps should only request access to the data they absolutely need for
their functionality and always with informed consent from the user
• apps should share data with third parties only when necessary, and this
should include enforcing that third-party SDKs operate based on user
consent, not by default or without it
• apps should be aware of the 'supply chain' of SDKs they incorporate,
ensuring that no data is unnecessarily passed down their chain of
dependencies.
• the app prevents identification of the user
• the app is transparent and offers user control over their data
IV. Network communication
• don’t trust the network, assume all communication can be intercepted
• use HPPTS to call backend services from the mobile app
• do not override SSL certificate validation to allow self-signed or invalid
certificates
• avoid mixed version SSL sessions
• encrypt data even if sent over SSL, in case of future SSL vulnerabilities
• use strong, industry standard cipher suites, with appropriate key lengths.
• use certificates signed by a trusted CA provider
• avoid sending sensitive data via SMS.
V. User Interface
• mask sensitive information on UI fields to prevent shoulder surfing
• inform the user about security-related activities, such as logins from
new devices
• validate and sanitize all user input
• validate and sanitize output to prevent injection and execution attacks
VI. Code quality
• use static analysis tools to identify vulnerabilities.
• perform code audits
• focus on security issues during code reviews
• keep all your libraries up to date to patch known vulnerabilities
VII. Application integrity
• disable debugging
• include code to validate integrity of application code
• obfuscate the app binary
VIII. Penetration Testing
• do penetration testing of the mobile application
IX. Post deployment
• respond to post deployment security incidents
• produce patches and updates
• code mechanisms that force users to update the mobile app
• monitor the usage logs to discover security incidents (of the backend
service)