Do’s |
Dont’s |
Sensitive data should stay in RAM for as little time as possible (Prevent data leak) |
Send sensitive data over alternate channels (e.g, SMS, MMS, or notifications) (They are not encrypted) |
Address Space Layout Randomization (ASLR) should be taken advantage of (Limit the impact of attacks such as buffer overflow) |
Encryption keys remain in RAM during the instance lifecycle of the app. (Prevent the key from being read from memory) |
minimize the use of APIs that access sensitive or personal user data (Prevent data leak) |
Write data to log files (Other applications can access the log data) |
Consider using a hash or non-reversible form of the data (To protect the original data) |
Store/cache sensitive data on the device (It can be leakded) |
minimize the frequency of asking for user credentials. Instead use an authorization token and refresh it (Less chance of exposing user credentials) |
storing/logging GPS data (Protect user privacy) |
Use secure POST to send user data, with XSRF token protection (Query params in URL are logged) |
Sending crash logs over the network in plaintext (Can contain sensitive info) |
Add an additional layer of verified, third-party encryption (e.g., SQLCipher) to the data as device encryption is not sufficient (Extra layer of protection) |
This repository has been archived by the owner on Apr 17, 2023. It is now read-only.