Mobile Application Security – OWASP MASVS

Mobile Application Security – OWASP MASVS

Mobile application security protects:

* User credentials

* Authentication tokens

* Personal information

* Financial information

* Local application data

* Network communication

* Application code and business logic

OWASP MASVS—Mobile Application Security Verification Standard—provides security and privacy requirements for mobile applications. This tutorial focuses only on the requested control groups:

1. Storage
2. Cryptography
3. Authentication
4. Network
5. Platform
6. Privacy
7. Resilience

Official OWASP MASVS control groups

1. Security Architecture

flowchart TD
    A["Mobile Application Security"] --> B["Storage"]
    A --> C["Cryptography"]
    A --> D["Authentication"]
    A --> E["Network"]
    A --> F["Platform"]
    A --> G["Privacy"]
    A --> H["Resilience"]

---

2. MASVS-STORAGE: Secure Local Storage

Storage security protects sensitive information stored on the device. OWASP divides this area into securely storing sensitive data and preventing accidental leakage. OWASP MASVS-STORAGE

Sensitive data examples

* Access and refresh tokens

* Personal information

* Bank-account information

* Health information

* API responses

* Encryption keys

* Session information

* User documents

Storage locations

Recommended approach

flowchart TD
    A["Data needs local storage"] --> B{"Is it sensitive?"}
    B -- No --> C["Use suitable app storage"]
    B -- Yes --> D{"Must it be stored?"}
    D -- No --> E["Keep only in memory"]
    D -- Yes --> F["Encrypt sensitive data"]
    F --> G["Protect key with Android Keystore"]

What should not be stored?

Avoid storing these unless a strict requirement exists:

* Raw password

* OTP

* MPIN

* CVV

* Complete card number

* Biometric information

* Private cryptographic key outside Keystore

* Sensitive API key inside the APK

Authentication should be based on secure tokens, not a locally stored password.

Internal storage

Internal storage is private to the application sandbox.

context.openFileOutput("profile.json", Context.MODE_PRIVATE).use {
    it.write(profileJson.toByteArray())
}

Private storage prevents ordinary apps from directly accessing the file, but it does not protect against every situation, such as a compromised device or unintended backup. Sensitive content may still require encryption.

Room security

Room does not encrypt its database automatically.

For sensitive Room data:

* Store only necessary fields.

* Encrypt sensitive values when required.

* Protect encryption keys using Android Keystore.

* Prevent sensitive database files from entering backups.

* Clear confidential data on logout when business rules require it.

* Never store passwords, OTPs or CVVs.

Prevent backup leakage

Sensitive application data should not enter uncontrolled cloud or device backups.

<application
    android:allowBackup="false"
    android:fullBackupContent="false">
</application>

For applications requiring backup, use backup rules to exclude only sensitive files instead of disabling all backup functionality.

Secure logging

Avoid this:

Log.d("Login", "Token: $accessToken")
Log.d("Payment", "Card: $cardNumber")

Prefer:

Log.d("Login", "Login request completed")

Production logs should exclude:

* Tokens

* Passwords

* OTPs

* Account numbers

* Personal information

* Complete request and response bodies

Clipboard protection

Do not automatically copy sensitive values such as:

* OTPs

* Card numbers

* Passwords

* Authentication tokens

Clipboard contents may be accessed or displayed by other system components.

Screenshot protection

For highly sensitive screens:

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

FLAG_SECURE helps prevent screenshots and display on non-secure surfaces, but it should be applied according to UX and business requirements.

Common storage mistakes

* Storing tokens as plain text

* Storing passwords in DataStore

* Logging complete API responses

* Saving sensitive files in public storage

* Putting secrets in source code

* Allowing sensitive data in backups

* Keeping confidential data after logout

* Assuming Room automatically encrypts data

---

3. MASVS-CRYPTO: Cryptography

Cryptography protects sensitive data using established encryption, hashing, signing and key-management mechanisms.

Main objectives

* Confidentiality: Unauthorized users cannot read data.

* Integrity: Unauthorized changes can be detected.

* Authenticity: The sender or data source can be verified.

* Key protection: Cryptographic keys remain secure.

Encryption vs hashing

> Mobile apps generally send passwords securely to the server. Password storage and password hashing should be handled by the authentication server using a suitable password-hashing algorithm.

Symmetric vs asymmetric cryptography

Recommended design

flowchart TD
    A["Sensitive data"] --> B["Encrypt with authenticated encryption"]
    B --> C["Encrypted data stored locally"]
    D["Key generated in Android Keystore"] --> B
    D --> E["Key remains non-exportable when supported"]

Android Keystore

Android Keystore provides protected storage for cryptographic keys.

It can provide:

* Non-exportable keys

* Hardware-backed key protection on supported devices

* Key-use restrictions

* User-authentication requirements

* Biometric-protected key usage

Example key generation:

val keyGenerator = KeyGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_AES,
    "AndroidKeyStore"
)

val keySpec = KeyGenParameterSpec.Builder(
    "secure_data_key",
    KeyProperties.PURPOSE_ENCRYPT or
        KeyProperties.PURPOSE_DECRYPT
)
    .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
    .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
    .build()

keyGenerator.init(keySpec)
keyGenerator.generateKey()

AES-GCM encryption

AES-GCM provides:

* Confidentiality

* Integrity verification

* Authentication of encrypted data

Important rules:

* Use a unique initialization vector for every encryption.

* Store the IV with the encrypted data.

* Never reuse an IV with the same key.

* Never create custom encryption algorithms.

* Do not hard-code encryption keys.

Cryptographically secure randomness

Use:

val secureRandom = SecureRandom()
val randomBytes = ByteArray(32)
secureRandom.nextBytes(randomBytes)

Do not use ordinary pseudo-random generators for:

* Security tokens

* Cryptographic keys

* Nonces

* Password-reset codes

Cryptographic mistakes

* Hard-coded encryption keys

* Keys stored in BuildConfig or resources

* Deprecated algorithms such as DES

* ECB mode

* Static or reused IVs

* Custom cryptographic algorithms

* Non-secure random-number generation

* Encryption without integrity protection

* Using Base64 as if it were encryption

> Base64 only represents binary data as text. Anyone can decode it.

---

4. MASVS-AUTH: Authentication and Authorization

Authentication confirms who the user is.

Authorization determines what the user is allowed to do.

OWASP requires secure authentication protocols, secure platform-based local authentication and additional authentication for sensitive operations. OWASP MASVS-AUTH

Authentication vs authorization

Secure authentication flow

sequenceDiagram
    participant U as User
    participant A as Android App
    participant S as Auth Server

    U->>A: Enter credentials
    A->>S: Send through HTTPS
    S->>S: Validate credentials
    S-->>A: Access and refresh tokens
    A->>A: Protect tokens
    A->>S: Request with access token
    S-->>A: Authorized response

Token management

Access token

* Short-lived

* Sent with protected API requests

* Used to authorize access

Refresh token

* Longer-lived

* Used to obtain a new access token

* Must receive stronger storage protection

* Should support server-side revocation and rotation

Token refresh flow

flowchart TD
    A["API request"] --> B{"Access token valid?"}
    B -- Yes --> C["Return response"]
    B -- No --> D["Refresh access token"]
    D --> E{"Refresh successful?"}
    E -- Yes --> F["Store new tokens safely"]
    F --> G["Retry original request once"]
    E -- No --> H["Clear session and request login"]

Simultaneous 401 handling

If several requests receive `401` together:

* Allow only one refresh request.

* Make the remaining requests wait.

* Store the new tokens once.

* Retry each original request once.

* Logout if refresh fails.

* Avoid infinite refresh loops.

An OkHttp Authenticator is commonly used for this behavior.

Server-side authorization

Never depend only on client-side UI checks.

This is insecure:

if (user.role == "ADMIN") {
    showAdminButton()
}

Hiding the button improves UI behavior but does not provide authorization. The server must validate:

* Token

* Role

* Resource ownership

* Requested operation

* Session status

Biometric authentication

Use Android’s BiometricPrompt rather than building a custom fingerprint interface.

val promptInfo = BiometricPrompt.PromptInfo.Builder()
    .setTitle("Confirm your identity")
    .setSubtitle("Authenticate to continue")
    .setAllowedAuthenticators(
        BiometricManager.Authenticators.BIOMETRIC_STRONG or
            BiometricManager.Authenticators.DEVICE_CREDENTIAL
    )
    .build()

Biometrics should unlock a protected key or authorize a local operation. Biometric success does not replace server-side authorization.

Step-up authentication

Sensitive operations may require fresh or additional authentication:

* Transferring money

* Changing password

* Adding a beneficiary

* Viewing highly sensitive data

* Changing registered phone number

* Exporting confidential documents

Normal session
      ↓
Sensitive operation requested
      ↓
Biometric, device credential or server verification
      ↓
Server authorizes operation

Logout requirements

A proper logout process should:

1. Revoke or invalidate the server session where supported.

2. Clear access and refresh tokens.

3. Clear sensitive cached data as required.

4. Cancel user-specific background work.

5. Clear sensitive notifications.

6. Return to the authentication screen.

7. Prevent protected screens from reopening through the back stack.

Authentication mistakes

* Storing passwords locally

* Long-lived access tokens

* Refreshing tokens without rotation or protection

* Trusting client-side roles

* Allowing unlimited retries

* Missing step-up authentication

* Keeping protected screens in the back stack

* Treating biometric success as server authorization

* Logging tokens

* Failing to expire sessions

---

5. MASVS-NETWORK: Secure Communication

Network controls protect data while it moves between the mobile application and backend systems. OWASP focuses on encrypted channels and, where appropriate, restricting trust to specific certificates or authorities. OWASP MASVS-NETWORK

Main threats

* Man-in-the-middle attacks

* Network interception

* Modified API responses

* Connection to an attacker-controlled server

* Cleartext HTTP traffic

* Incorrect certificate validation

Secure communication flow

flowchart LR
    A["Android app"] --> B["HTTPS and TLS"]
    B --> C["Certificate validation"]
    C --> D["Trusted backend"]

HTTPS and TLS

Use HTTPS for all sensitive communication:

https://api.example.com

Avoid:

http://api.example.com

TLS provides:

* Encryption

* Server authentication

* Message integrity

Network Security Config

Create res/xml/network_security_config.xml:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
</network-security-config>

Register it:

<application
    android:networkSecurityConfig="@xml/network_security_config"
    android:usesCleartextTraffic="false">
</application>

Debug-only certificates

Development certificates should not be trusted in production:

<debug-overrides>
    <trust-anchors>
        <certificates src="@raw/debug_ca" />
    </trust-anchors>
</debug-overrides>

This keeps debug trust separate from release behavior.

Certificate pinning

Certificate pinning restricts the certificates or public keys trusted for a particular host.

flowchart TD
    A["Connect to server"] --> B["Validate TLS certificate"]
    B --> C["Compare pin"]
    C --> D{"Pin matches?"}
    D -- Yes --> E["Continue connection"]
    D -- No --> F["Reject connection"]

OkHttp example:

val certificatePinner = CertificatePinner.Builder()
    .add(
        "api.example.com",
        "sha256/PRIMARY_PUBLIC_KEY_PIN",
        "sha256/BACKUP_PUBLIC_KEY_PIN"
    )
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

Pinning risks

Incorrect pinning can make the application unable to connect after certificate rotation.

A safe operational plan requires:

* A backup pin

* Certificate-rotation planning

* Monitoring before expiry

* A secure app-update process

* Testing with the future certificate

* A recovery strategy

Pinning is a risk-based control, not an automatic requirement for every application.

Network mistakes

* Allowing cleartext HTTP

* Trusting every certificate

* Disabling hostname verification

* Using a permissive TrustManager

* Logging request headers containing tokens

* Shipping debugging proxy certificates

* Pinning without backup pins

* Hard-coding expired certificates

* Sending secrets in URL query parameters

* Assuming HTTPS secures a compromised endpoint

---

6. MASVS-PLATFORM: Secure Platform Interaction

Platform controls secure interactions between the application, Android OS and other installed applications.

Main areas

* Application components

* Intent handling

* Deep links

* WebView

* Permissions

* File sharing

* Notifications

* IPC

* PendingIntent

* Screenshots and overlays

Exported components

Android components include:

* Activities

* Services

* BroadcastReceivers

* ContentProviders

Declare export behavior explicitly:

<activity
    android:name=".InternalActivity"
    android:exported="false" />

An exported component can potentially be accessed by another application.

For exported sensitive components:

* Require appropriate permissions.

* Validate every Intent.

* Validate the caller where applicable.

* Never trust extras received from another app.

* Enforce authorization again.

Intent validation

Do not trust external input:

val accountId = intent.getStringExtra("account_id")

Validate it before use:

val accountId = intent.getStringExtra("account_id")

if (accountId.isNullOrBlank() || !accountId.matches(Regex("[A-Za-z0-9-]+"))) {
    finish()
    return
}

More importantly, the backend must confirm that the authenticated user owns the requested account.

Deep-link security

flowchart TD
    A["Deep link received"] --> B["Validate scheme and host"]
    B --> C["Validate path and parameters"]
    C --> D{"Authentication required?"}
    D -- Yes --> E["Authenticate user"]
    D -- No --> F["Continue"]
    E --> G["Check authorization"]
    F --> G
    G --> H["Open destination"]

Validate:

* Scheme

* Host

* Path

* Query parameters

* Authentication state

* Authorization

* Redirect destination

Never place tokens, OTPs or sensitive information in deep-link URLs.

Verified App Links

Use HTTPS App Links and domain verification:

<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />

    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />

    <data
        android:scheme="https"
        android:host="example.com" />
</intent-filter>

Verification helps associate the website domain with the application, but the app must still validate the URL and user authorization.

Secure PendingIntent

Prefer immutable PendingIntents when mutation is unnecessary:

val pendingIntent = PendingIntent.getActivity(
    context,
    100,
    intent,
    PendingIntent.FLAG_UPDATE_CURRENT or
        PendingIntent.FLAG_IMMUTABLE
)

Use unique request codes where different actions must remain independent.

Secure file sharing

Do not expose raw file paths. Use FileProvider with narrow path configuration and temporary URI permissions.

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Avoid broad file-provider paths such as an entire storage root.

WebView security

If a WebView is required:

* Load trusted content.

* Use HTTPS.

* Disable JavaScript when unnecessary.

* Validate URLs before loading.

* Avoid unsafe JavaScript interfaces.

* Restrict file access.

* Prevent navigation to untrusted schemes.

* Do not ignore TLS errors.

webView.settings.javaScriptEnabled = false
webView.settings.allowFileAccess = false
webView.settings.allowContentAccess = false

Never continue after an SSL error simply to make a page load.

Permission minimization

Request only permissions required by an active feature.

Examples:

* Request camera permission when scanning begins.

* Request location permission only for a location feature.

* Avoid requesting contacts when a user can select a contact through a system picker.

* Explain why sensitive access is needed.

Platform-security mistakes

* Unnecessarily exported components

* Trusting Intent extras

* Unvalidated deep links

* Mutable PendingIntent without need

* Broad FileProvider paths

* Loading untrusted content in WebView

* Unsafe JavaScript interfaces

* Excessive permissions

* Sensitive content in notifications

* Exposing internal screens to other apps

---

7. MASVS-PRIVACY: User Privacy

Privacy controls protect personal data and help users understand and control its use.

OWASP MASVS-PRIVACY provides an app-focused privacy baseline, but it does not replace a complete legal or regulatory privacy assessment. OWASP MASVS-PRIVACY

Personal-data examples

* Name

* Email address

* Phone number

* Location

* Contacts

* Device identifiers

* Advertising identifiers

* Photos and videos

* Health information

* Financial information

* Usage analytics

* Biometric-related information

Core privacy principles

Data minimization

Collect only the information required for the feature.

Can the feature work without this data?
        |
   +----+----+
   |         |
  Yes        No
   |         |
   v         v
Do not     Collect only
collect    required data

Purpose limitation

Use collected data only for the purpose communicated to the user.

For example, location collected for navigation should not automatically be used for advertising.

Transparency

Inform the user:

* What data is collected

* Why it is collected

* Where it is sent

* How long it is retained

* Whether third parties receive it

* How the user can delete it

User control

Where applicable, allow users to:

* Grant or deny permission

* Withdraw consent

* Disable optional analytics

* Export their information

* Correct information

* Delete account and data

Retention limitation

Do not retain information indefinitely.

Collect data
    ↓
Use for declared purpose
    ↓
Retention period completes
    ↓
Delete or irreversibly anonymize

Permission vs consent

Receiving a platform permission does not automatically provide unrestricted consent for unrelated processing.

Third-party SDKs

Analytics, advertising and crash-reporting SDKs may collect data.

Before adding an SDK:

* Identify what it collects.

* Verify which endpoints receive data.

* Review configuration defaults.

* Disable unnecessary collection.

* Avoid sending personal data in event properties.

* Document it in privacy disclosures.

* Review SDK updates.

Privacy mistakes

* Collecting unnecessary identifiers

* Starting tracking before required consent

* Sharing data with undisclosed third parties

* Keeping data indefinitely

* Recording sensitive analytics events

* Including personal information in crash reports

* Requesting excessive permissions

* Making account deletion unnecessarily difficult

* Assuming anonymized data cannot be reidentified

---

8. MASVS-RESILIENCE: Tampering and Reverse Engineering

Resilience controls make it more difficult to analyze, modify, repackage or abuse the application.

These controls are particularly important for:

* Banking apps

* Payment apps

* DRM applications

* Games with anti-cheat requirements

* Apps containing valuable business logic

* Apps operating in high-risk environments

Resilience does not make an APK impossible to reverse engineer.

Common threats

* APK decompilation

* Code modification

* Application repackaging

* Runtime method hooking

* Debugging

* Rooted-device manipulation

* Emulator-based analysis

* Fake application distribution

* Modification of local business rules

Defence-in-depth architecture

flowchart TD
    A["Application starts"] --> B["Integrity and environment checks"]
    B --> C["Obfuscated application code"]
    C --> D["Secure server communication"]
    D --> E["Server validates sensitive operations"]
    E --> F["Monitor suspicious behaviour"]

R8 obfuscation

Release configuration:

buildTypes {
    release {
        isMinifyEnabled = true
        isShrinkResources = true
        proguardFiles(
            getDefaultProguardFile(
                "proguard-android-optimize.txt"
            ),
            "proguard-rules.pro"
        )
    }
}

R8 can provide:

* Code shrinking

* Resource shrinking

* Optimization

* Class and method-name obfuscation

R8 increases reverse-engineering effort but does not provide complete protection.

Application signing

Android application signing helps verify:

* Application identity

* Update authenticity

* Package ownership

Protect signing keys using:

* Restricted access

* Secure CI/CD secrets

* Key rotation planning

* Separate debug and production keys

* Play App Signing where appropriate

Never:

* Commit signing keys to Git

* Share production keystores through email

* Store passwords directly in build scripts

Integrity validation

Integrity checks can help detect:

* Repackaged applications

* Untrusted installations

* Modified application binaries

* Suspicious devices or environments

However, the server should interpret integrity signals as part of a broader risk decision. A client-side check can itself be modified or bypassed.

Root and compromised-device detection

A compromised device may weaken:

* Application sandboxing

* Keystore assumptions

* Runtime integrity

* Local file protection

Possible responses depend on risk:

* Record a risk signal

* Warn the user

* Require additional authentication

* Restrict selected high-risk operations

* Block access only when justified

Root detection alone should not be treated as perfect proof because it may produce false positives and can be bypassed.

Anti-debugging and anti-hooking

Applications may detect:

* Attached debuggers

* Runtime instrumentation

* Unexpected libraries

* Modified execution environments

* Suspicious application signatures

Use these as layers, not as the sole security control.

Do not trust client-side business logic

An attacker controls their device and may modify the app.

Do not rely on the app alone for:

* Payment amount validation

* Discount calculation

* Account ownership

* Subscription status

* User role

* Transaction limits

* Access-control decisions

The server must validate sensitive operations.

Resilience mistakes

* Believing obfuscation makes code secure

* Storing secrets in native code

* Depending only on root detection

* Blocking legitimate users without a risk policy

* Keeping critical authorization logic only on the client

* Exposing readable internal information through logs

* Using the same signing keys for debug and release

* Treating integrity verdicts as the only security decision

---

9. Complete Secure Mobile Flow

flowchart TD
    A["User authenticates"] --> B["Server validates identity"]
    B --> C["Short-lived access token"]
    C --> D["Token protected locally"]
    D --> E["HTTPS request"]
    E --> F["Server checks authorization"]
    F --> G["Minimum required data returned"]
    G --> H["Sensitive data protected in storage"]
    H --> I["Integrity and privacy monitoring"]

---

10. Banking Application Example

Secure payment flow

flowchart TD
    A["User enters payment"] --> B["Validate input locally"]
    B --> C["Require step-up authentication"]
    C --> D["Send through HTTPS"]
    D --> E["Server verifies user and limits"]
    E --> F["Server executes transaction"]
    F --> G["Return transaction reference"]
    G --> H["Display server-confirmed status"]

The Android application should never independently decide that a payment succeeded. Final status must come from the server.

---

11. Common Interview Questions

1. What is OWASP MASVS?

OWASP MASVS is a security and privacy verification standard containing requirements for building and evaluating secure mobile applications.

2. What is the difference between data at rest and data in transit?

Data at rest is stored on the device and is addressed by storage and cryptography controls. Data in transit moves between systems and is protected using secure network communication such as HTTPS/TLS.

3. Where should an Android app store encryption keys?

Cryptographic keys should generally be generated and protected through Android Keystore rather than hard-coded or stored in normal files.

4. Should passwords be stored in DataStore?

No. The application should authenticate with the server and manage secure tokens. It should not persist raw passwords.

5. Is Base64 encryption?

No. Base64 is an encoding format and provides no confidentiality.

6. What is the difference between authentication and authorization?

Authentication verifies the user’s identity. Authorization determines what that authenticated user may access or perform.

7. Does hiding an admin button provide authorization?

No. The server must validate the user’s role and permission for every protected operation.

8. Why are short-lived access tokens recommended?

They reduce the time in which a stolen token can be abused.

9. How should simultaneous 401 responses be handled?

Only one token-refresh operation should run. Other requests should wait and retry once after refresh succeeds.

10. What does HTTPS protect?

HTTPS/TLS protects confidentiality, integrity and server authentication during network communication.

11. What is certificate pinning?

It restricts a host connection to expected certificates or public keys. It requires backup pins and a certificate-rotation strategy.

12. Why must deep links be validated?

Deep links are external inputs and may attempt to open unauthorized screens, inject parameters or redirect users.

13. Why use immutable PendingIntent?

It prevents another party from modifying the wrapped Intent when mutation is unnecessary.

14. Does R8 completely prevent reverse engineering?

No. It increases the effort required but cannot make an APK impossible to analyze.

15. Can root detection guarantee device security?

No. It is a risk signal that can produce false results and may be bypassed.

16. Should sensitive business rules exist only inside the app?

No. Attackers can modify the client. The server must validate authorization and sensitive business operations.

17. What is data minimization?

It means collecting, processing and retaining only the data necessary for the declared purpose.

18. Does Android permission equal privacy consent?

Not necessarily. A platform permission authorizes device access, while consent addresses how and why personal data is processed.

---

12. Security Checklist

Storage

* Do not store passwords, OTPs, MPINs or CVVs.

* Keep sensitive data out of logs and backups.

* Use private storage.

* Encrypt sensitive persisted data when required.

* Clear sensitive session data on logout.

Cryptography

* Use standard, modern algorithms.

* Protect keys with Android Keystore.

* Use secure random values.

* Never hard-code keys.

* Never create custom cryptography.

Authentication

* Use short-lived access tokens.

* Protect refresh tokens.

* Enforce authorization on the server.

* Use secure biometric APIs.

* Require step-up authentication for sensitive operations.

Network

* Use HTTPS.

* Disable cleartext traffic.

* Validate certificates and hostnames.

* Do not use permissive TrustManagers.

* Plan pin and certificate rotation.

Platform

* Minimize exported components.

* Validate Intents and deep links.

* Use immutable PendingIntents where appropriate.

* Restrict WebView and FileProvider access.

* Request minimum permissions.

Privacy

* Collect minimum necessary information.

* Clearly explain data usage.

* Review third-party SDK collection.

* Support required user controls.

* Delete data according to retention rules.

Resilience

* Enable R8 for release builds.

* Protect signing keys.

* Validate important operations on the server.

* Use integrity and device-risk signals carefully.

* Treat all client-side controls as bypassable.

---

Quick Revision

STORAGE
    → Protect data stored on the device

CRYPTO
    → Use secure algorithms and protect keys

AUTH
    → Verify identity and enforce permission

NETWORK
    → Protect data sent between app and server

PLATFORM
    → Secure Intents, components, WebViews and permissions

PRIVACY
    → Collect and use only necessary personal data

RESILIENCE
    → Increase resistance to tampering and reverse engineering

Security should be implemented as multiple layers:

Secure storage
    + Strong cryptography
    + Secure authentication
    + HTTPS/TLS
    + Platform validation
    + Privacy controls
    + Server-side enforcement
    + Tamper resistance