When developing new applications, a particularly web based or mobile applications, software development teams often find themselves fixing vulnerabilities that either have been found during a pentest, or worse still, have been exploited during an attack.
Besides bugs, our users can benefit from good security features. Unfortunately, whereas there is a very good web application weakness taxonomy available (OWASP), the equivalent taxonomy for application features is not very well known OWASP Application Security Verification Standard (ASVS). Based on OWASP and my experience, the following are the secure development principles and features I recommend:

1. Protect Sensitive Information (e.g Secrets, Personal Information, Funds, Intellectual Property, passwords, session tokens) stored on the client side. Sensitive Information stored on the client side shouldn't be possible to read without the user credential, via the application or reading the filesystem directly. This is normally implemented using operating system facilities or libraries to encrypt the personal identifiable information, passwords and tokens. Proper permissions settings in files and folders is a complementary technique.
2. No unnecessary files should be left in the cache or client filesystem upon session logout or upon uninstall.
3. Protect Sensitive Information stored on the server side. This is normally implemented using operating system facilities or libraries to encrypt the personal identifiable information, passwords and tokens. Ideally the server side should not store the password, but a salted hash (a mathematical proof of knowledge of the password)
4. Performing reverse engineering or creating copycats of the application should require special skills and be time-consuming. There are several techniques that can prevent or hamper reverse engineering, among them:

Obfuscating the code.
Preventing the application from running on virtual machine environments.
Preventing the application from running on rooted devices.
Periodically checking the application digital signature.
The user could choose the look of the application icon upon installation.

1. The user should only be able to move between pages following the designed flow.
2. Data input should be validated preventing it from being interpreted as code. This includes the entry of actual code, unsupported unicode codes, or maliciously crafted encodings that can be interpreted or used by the frontend or backend as code. A possible undesirable side effect is potentially uploading files to the server side.
3. Error codes given by the application should not reveal internal logic on the server or client sides. During QA error codes will help pinpointing errors and bugs, but the production application error codes should be "cleaned" or made generic in order not to provide clues on internal logic of the application for potential attackers.

4. The application must not let users operate from locations where there is a high risk of illegal activity or where the organization doesn't operate. Several techniques can be used to detect the location of the device:
   Geolocation via GPS
   Geolocation via IP
   Identification of possible VPN or Proxy use to conceal location

5. The user should be able to interact with current information only. The user should not be able to interact with outdated information that is no longer valid. Ideally the user should not be able to view information that is no longer valid. The status of the invalid (as not current) information should be visually evident for the user.

6. All significant events and Sensitive Information events must be logged.

7. All User Registration events must be logged, including:
   User Account Creation (successful or not)
   User Account Suspended (successful or not)
   User Account Reactivated (successful or not)
   Credential Reset (successful or not)
   Credential expiration
   Credential changes (successful or not)
   Login (successful or not)
   Session closed or expired

8. The log format and syntax should facilitate the detection of anomalies.

9. Sensitive information and user registration logs of events should be protected from tampering even if the admin account was compromised.

10. In order to protect the user's privacy the communication between the application and and the server has to be strongly encrypted end to end. Encryption is a means to an end: The client side should be able to check it is communicating with the organization and not an impostor, the organization should be able to check the client is a legit user and not a malicious bot, and the communication should be protected from snooping by third parties. This can be achieved using a combination of technologies:
    Certificate or key pinning on the client side.
    Use of SSL certificates on the server side.
    Using HTTPS
    Enforce HSTS on the server side (for the web application if there is one)
    Checking for Certificate Transparency validity.

11. Protection of the user session after login from stealing and replaying. There are several techniques that can offer protection:
    Making Session IDs random
    Linking the Session ID to a fingerprint of the device, and validating the fingerprint of the device periodically.
    Protection of the session token
    Allowing the user to terminate the session
    Allowing the user to configure a maximum session duration
    Setting a hard maximum session duration

12. Protection of the user session upon login. Several techniques can prevent malicious users to login using the legitimate user's credentials:
    Imposing a delay between login attempts
    The delay can increase the more login attempts are recorded in a period
    The user should be notified via email of all logins, successful or not.
    Fine tune all the above depending of the device fingerprint being known to be linked to the user or not

13. Protection of the credentials lifecycle (normally passwords). The password lifecycle should be protected with techniques like the following:
    Provide the user feedback on how strong his password choice is
    Imposing a minimum password length
    Enabling the user to change his password on demand. When changing the password in the application it self, the password must be typed in order to access this functionality. The user will receive a notification of the change event.
    The channel used to facilitate the actual credential change MUST be different from the channel used to request it.
    Enabling the user to reset his password if it has been forgotten, with the following caveats: The reset token should work only for a limited time, The user will be notified both about the password request change and the password change events

14. The production application should not contain any developer's comments.

15. The user should only be able to access his own information, never information of other users, or information unrelated with his user account.

16. It should not be possible to use the application in a way that the user obtains a unfair, undesigned or fraudulent gain.

17. The application should run in way that makes impossible or obvious the presence of screen overlays.

18. The client application should be able to respond to a server challenge. This will enable prioritizing valid traffic versus malicious bots. Challenges can range from captcha to "secret knocking" or Proof of Work algorithms.

19. The user should be able to determine

if the installed application is original and untampered or not. The application should use code signing in a way that it is obvious for the user if it has been tampered with.

1. The user should be able to configure a maximum session duration. We want to guarantee that only the owner of the user account can use it. The user may prefer to be prompted for his credential more often than the maximum time out period would

2. When login from a non-trusted Location the system should:
   Deny access for high risk locations
   or Request a token sent via email of text message to complete login.
   or Request a captcha to be solved

3. When login from a non-trusted Network the system should:
   Deny access for high risk IPs
   or Request a token sent via email of text message to complete login.
   or Request a captcha to be solved

4. When login from a non-trusted Device the system should:
   Deny access for high risk Devices
   or Request a token sent via email of text message to complete login.
   or Request a captcha to be solved

5. User account IDs can't be reused, even if the account has been previously cancelled.

6. The following events should prompt a notification via text message or Email sent to the User of the system concerned
   User account locked
   User account unlocked
   Multiple Login Requests Denied
   Credential change granted
   Credential change requested
   Log in from a new device
   Log in from a new location
   Change of language

The user can only take action if someone is trying to take over the account if he or she is aware of it.

1. Logs should not be modifiable even with privileged access, any modification should be detectable and reversible. This is a backend feature that would protect us even if a full scale breach compromised our systems.
2. Credentials must not expire. According to the latest guidance by NIST, forcing credential changes does not increase security. Also, it is not helpful usability wise.
3. Sessions should have a maximum time out period, regardless of being in use or not
4. Password quality should be measured based on entropy only, without forcing complexity. In practice the quality of the credential increases the fastest with increasing length, not complexity.
5. The user must get feedback on the quality of the credential while choosing it. Users don't have the skills to determine the quality of their passwords, providing them with feedback can help them choose the level of security and/or inconvenience they prefer. 35: The user should be able to choose his credential. User often want to choose their credentials, as it is often the easiest way for them to remember them.
6. The user should be able to have the system suggest a high quality credential for him (client side code only) Users don't have the skills to choose high quality passwords, long enough, easy to type and easy to remember. System suggestions can help them, enhancing the chances that only the owner of the user account will use it.
7. The user should be able to recover his credential after proving his ownership of his email address or phone number.
8. The user should be able to change his credential in the system itself, immediately after proving knowledge of the current credential
9. Simultaneous sessions with the same user account ID should be limited in number. As each session uses system resources, unlimited sessions can lead to Denial of Service.
10. 2FA/MFA should be available for the user. We want to guarantee that only the owner of the user account can use it.
11. Login information is validated only on completion of all input data. If an error condition arises, the system does not indicate which part of the data is correct or incorrect and requires the user to try again.
12. Information on past successful (date and time) and unsuccessful logins (number) is provided on completion of a successful login. The user can only take action if someone is trying to take over the account if he or she is aware of it.
13. The user should have the option to hide the credential characters with symbols while typing it. If an attacker near the user can view the password and account ID while is input, the attacker can hijack the account of the user.
14. The user should be able to use a password manager to input his credential. If the credential is complex, the user needs a password manager to be able to input the credential reliably.
15. Emails notifications regarding security events, status or actions should not have links. links in emails train users to click on anything they receive, so they become more vulnerable to phishing attempts

Very well worth checking the Minimum Viable Secure Product also