Checklist

Whether it is your developers, business partners, designers, or anyone else you work with, perform a thorough background check and choose to work only with reputed ones who have a credible market standing. Review their websites, ask for testimonials and check with past clients before making them a part of the team. You can snoop around at Better Business Bureau to see if they’ve ever been accused of copyright infringement or violation of confidentiality.

You can’t ‘not tell’ your team of developers about your idea. In fact, they’ll need to know every little detail if they are to execute it to perfection. So to keep them from sharing your idea with your rivals or anyone else, you need to get them to sign a Non-Disclosure Agreement or NDA. Violating an NDA puts their reputations at risk and hence, they will make sure they abide.

While there are laws and systems to protect intellectual property, there’s really not much that can be done to protect just an ‘idea’. You need to have something tangible, to protect it. Your best bet is to get working and create something – a code, or an MVP – that can be protected.

A non-compete agreement entails that a developer working on your project cannot work on any other project simultaneously. This means that they will not work for any of your rivals for the duration of your project, sometimes restricting them even a few months after they’ve finished working on your app.

Of course, this turns out to be an unprofitable situation for the developer and hence, you’d be hard-pressed to find someone who’ll sign, but you could try.

Patents take time. They’re not the easiest thing to obtain. Many states also do not offer patents for computer software. These and other factors make it fairly complex to patent your idea. However, some programs have been patented, so you could check with a patent attorney if your app idea or a part thereof can be patented.

One way of tackling this complexity is to file a provisional patent application. It has a lower fee – only $130 for small businesses – and it protects your idea for a year. It automatically expires after a year, but that gives you enough time to get your app rolled out successfully.

Your app’s name, logo, icons and other important assets can be trademarked, preventing anyone from imitating or outright copying them. The trademarks also help create a dated document trail that can be cited as evidence to prove who had the idea first, in case the matter ever goes to trial.

Your app developers are privy to every little thing about your app, so before they finish working with you and move on, get them to legally hand over every single line of code and give you exclusive rights, renouncing any claim.

If you come across someone who infringed on your idea, call them out and pursue them fiercely. Doing so will effectively deter others from messing with you.

Physical breaches such as lost or stolen devices can easily be susceptible to identity theft and severe damages. App developers must make extremely secure arrangements for data storage, so that no hacker can access sensitive stored information like credit card numbers, social security numbers, home addresses and much more.

Some of the biggest hackings, malware or spyware attacks happen due to weak password requirements and checks. A corporate study by password management firm Meldium found that 65% of people use the same password everywhere, making it possible for hackers to crack 90% of employee passwords within 6 hours. App developers must make sure the app will only accept high security passwords that are at least eight characters, alphanumeric with at least one special character. Users will surely understand when they see how this is important.

Apart from stealing data from the client side, that is, from the user’s phone, hackers can also intercept communications from the server and steal data from there. That is why it is extremely important to strengthen your server side controls, making data on the server impenetrable. Developers often underestimate the importance of server security either due to lack of knowledge or budget

Criminals can reverse engineer your app and inject it with a malicious code that can lead to data theft and all other possible damages to the app users. To prevent this, you need to secure your app code using binary protection and code obfuscation so that they cannot be reverse engineered. Analyze all your binary files to identify and deflect common exploits. Also follow secure coding techniques for jailbreak detection, checksum controls and debugger detection.

Data needs to be protected while on the device and while on the server. Additionally, data also needs to be protected while it is on the move, or while it’s being transported from the device to the server and vice versa. This is where transport layer security comes into play. By intercepting the paths that data follows during client to server exchange and back, a criminal can easily steal all the secure data and cause plenty of damage.

Unintentional data leakages happen on the user’s device when certain parts of critical data are saved in the common phone memory that is accessible to other apps. This allows that data to get into the hands of other apps or other users, both resulting in theft and unauthorized usage. To avoid such a scenario, developers must take stock of all the various places in the app where data leakage can potentially take place, such as the cache, logging, cookies, HTML5 data and other places.

Since mobile phones are used continually throughout the day and are rarely ever shut down, it is possible that a user may forget to specifically log out of an app after finishing a task. This allows third part users to access the app and cause damage, especially if the phone is lost or stolen. According to Consumer Reports, 5.2 million smartphones were lost or stolen in the US in 2014. According to Bitglass Cloud Security, 25.3% of financial data breaches from banks are due to lost phones and laptops.

Mobile apps cache important information to provide users a fast and seamless experience. However, caches are an easy target for hackers and hence, should never be used to store sensitive information like credit card numbers.

Third-party libraries are a developer’s best friends, when they need to get things done quickly. However, sometimes, there are bugged libraries up for grabs and at other times, hackers deliberately plant faulty code in libraries, hoping somebody will use them in an app, giving them a chance to attack the app. Thorough research is crucial before using any third-party code.

You can use Application Threat Modeling to emulate how a hacker would try to breach your app, and then secure against it. Think of yourself as a hacker and device all possible ways you could hack into the app. Then, secure all those areas and protect the app from all the ways you think it can be exploited. This would involve decomposing the application, determining rank threats using categorization methodology like STRIDE, and lastly, deploying mitigation and counter measures.

From the very outset, use a security framework and follow the best coding practices. Using the OWASP Secure Coding Guide will help you make sure your code is tight as a tick. Following such a framework helps you eliminate or at least reduce risk to a minimum, right from the start, leaving little to no gaps for a criminal to slip through.

Encrypting data at rest and in transit ensures that even if a hacker breaks in to your app and steal it, he cannot read it or decipher much to cause any real damage. Encryption scrambles the data in a way that only the authorized system with an encryption key or cipher can read the data, and no one else. If you find that you cannot encrypt every bit of data in the early stages, you may have to choose a piecemeal approach and encrypt parts of the data. In that case, always ensure that the sensitive data must be protected, and hence, effectively encrypted.

Authentication simply refers to passwords and other personal identification barriers to entry. A strong password is your first protection against hackers. So first of all, design your app to accept only high security passwords that are at long, alphanumeric with at least one special character. Secondly, using multi-factor authentication must be absolutely imperative in sensitive operations like money transfer and mobile payments, so a combination of pin/password and an OTP or some other dynamic form of user-specific authentication must be adopted. Biometric authentication like fingerprints and retina scans may also be employed in particularly sensitive operations. Allow only non-sensitive parts of the app to work when the app is being used offline. Logins and sensitive data transport should ideally not be allowed while offline.

Protecting the data on the server is an important part of the mobile app security landscape. You can use methods such as containerization and database encryption to secure backend data. Conduct penetration testing to assess vulnerabilities and secure all data effectively.

Proper identification, authentication and authorization of API’s is integral to mobile app security as developers use APIs so liberally in apps. Encrypt API traffic with SSL and TLS to keep data secure during transfer. Use OAuth2 for managing the exchange of tokens and deploy two-factor authentication for an added layer of security.

Testing over and over again is the most authentic way to secure you app against any kind of risk. You can execute static application security testing or SAST using tools like AppScan, Veracode and Sonar or even use Dynamic Application Security Testing or DAST to test the app while it is running. Using a combination of these two testing methodologies helps you test individual aspects of the app to cover maximum ground. Automate scanning and testing wherever possible, to get real time reports on runtime errors.

The Android Playstore and Apple App Store together contain about two billion apps. It is practically impossible to vet each app submitted to the app store and hence, buggy apps and malicious content may sometimes make it through to the app store. So don’t blindly rely on the app store security protocols and have your own security standards in place to begin with.

There will always be the problem of physical breach due to lost or stolen devices, which happen to be in millions by the way. So make sure you have protocols in place to end session, remote wipe and block access to your app in such a condition.