Whenever a mobile app communicates with a server, we say it is using an external API.
This is what allows the transfer of your data between the mobile app and the server running in the cloud. These days this almost always happens over HTTPS, on the Internet.
APIs can expose any and all of your data. Because of this, if yours is not designed correctly, it can be a security nightmare – exposing your data to hackers and other nefarious actors on the internet.
If your API is not designed correctly, it can be a security nightmare – exposing your data to hackers.
Designing APIs for Security First
Microsoft
Years ago, Microsoft had a Come-To-Jesus moment with security.
After the Melissa, ILOVEYOU, Code Red, and Nimda viruses, Bill Gates made a proclamation that all further development of Windows must focus on security.
The end result was that their next Windows version (Windows Vista) was over 3 years late and took 6 years to develop and ended up being one of the least successful releases of windows.
Since Windows had never been developed as a hardened operating system prepared to handle external connections, it required years of work to make it “safe” to connect to the Internet.
Zoom
Another more current example is Zoom, which during this pandemic became one of the most popular methods of communication around.
It was designed for simplicity. To host a meeting you simply sent your colleagues a 9-digit meeting ID.
However, it was easy for someone to break into your private meeting by randomly guessing 9-digit numbers.
Zoom made a host of other security mistakes – rolling their own encryption package and including an out-of-date GIF library that allowed for remote code execution.
The lesson from these examples of Microsoft and Zoom is to design your APIs with security in mind from the onset. Adding security after an API is developed is painful, and sometimes fatal for a company.
60% Of Small Companies Close Within 6 Months Of Being Hacked (CyberCrime Magazine)
Best Practices When Designing APIs
As a non-security professional, and a non-developer, you should know what issues to be aware of so you can ask your developers or contractors intelligent questions about the security of the API being designed.
1. Secure Access Control Levels
Having different Access Control Levels is an important feature of any API that allows more power to more entitled Users.
One common mistake is enforcing Access Control Levels in the front-end only (i.e. the mobile app) and not on the back-end (the server).
What You Can Do: Ensure that all Access Control Level control occurs both on the front-end (for better user experience) and on the back-end (to ensure security).
2. Prevent SQL Injection
Even in 2020, the number one attack on an API will be an SQL Injection attack.
What You Can Do: Make sure your developers are building your systems in a way that is not vulnerable to SQL Injection attacks. Ensure your penetration tests include at least an SQL Injection Scanner.
3. Don’t Trust User Input
The two previous points (Securing Access Control Levels and SQL Injection) are basically subsets of this point – don’t trust data coming from the user.
You may think that your front-end has successfully sanitized (when programmers say sanitize that means that the data has been cleaned up and presented in a way appropriate for processing) all the input, but that will not stop a hacker from crafting a malicious API request after snooping on your data.
What You Can Do: Assume that all data coming in could be invalid, and sanitize it on the server as well.
In general, sanitize input on the client-side only to make the input look consistent and attractive to the user (for example adding dashes to phone numbers). Sanitize data on the server-side to prevent malicious behavior.
4. Never Roll-Your-Own Security
At some point in their career, every developer thinks that they can implement their own very clever security system — ensure this does not happen.
Rolling your own security is a recipe for disaster. No matter how smart you are, you are not as smart as the wisdom of the experts who create and audit authentication systems. You are also not as smart as some of the hackers out there!
What You Can Do: Pick an off-the-shelf authentication system, whether that is OpenID, OAuth, SAML, JAAS, or whatever the primary authentication system is for the platform you are writing on.
5. Avoid Security Through Obscurity
Some will argue (against the “never roll-your-own-security” mantra) that using custom code, cryptic names or obfuscated data, adds a level of security to your API. They say this because there is no documentation, or well-known strategies, on how to attack it.
What You Can Do: Never underestimate the ability of hackers to figure out whatever obtuse system you have invented. If they deem it interesting enough, they will.
While most attacks you experience will be “script kiddies”, if someone is willing to put in the work the things that can be done are shocking in their complexity.
6. Don’t Assume that HTTPS is a Silver Bullet
HTTPS (encrypted HTTP) will make it much more difficult for outside attackers to view your data. These days all API calls should be sent over HTTPS.
However, anyone running the API can relatively easily place a proxy in between the client (i.e. the app or website) and your servers and see everything that is posted in plain-text.
What You Can Do: Anything you do not want an end-user to see should not be sent to their computer or mobile device. Use JWT (JSON Web Tokens) or keep the sensitive data on your servers.
7. Do Not Expose More Information than is Necessary
As stated above, everything that is sent to the client, even if it is not actually displayed in the app, will be available to a bad actor.
What You Can Do: If you are passing information to the client (ex. the app) make sure that it is acceptable that Users should be allowed to view that information – because as stated above, unscrupulous Users will be able to see that information.
Even if you encode the data, if at some point on the end-users device you decode the data, hackers can use debugging tools to see all the text in memory on the device.
8. Avoid Storing Credit Card Information
While you may need to accept credit cards, use a payment provider where you are not required to maintain any of the credit card information on your servers. Even if you must use recurring billing.
Also, double-check to make sure that you aren’t accidentally saving credit card information to your logs. The first place a hacker will go to look for passwords and credit card numbers is the logs.
9. Don’t Save Passwords
The storage and validation of passwords should be passed off to a library of some kind (see point #4 above). Ensure that you are not storing passwords in any way — whether through accidental logging, or some kind of poorly-thought-out password recovery system.
10. Tap the Knowledge of the Group
Have your IT staff, developers, security engineers and anyone else who has a creative mind, try to think of ways that your APIs might be exposed to hackers.
You might have a Friday afternoon bug bounty where employees can win a gift card if they spot a flaw in the proposed API, or an active API.
What You Can Do: It is also important to make sure your engineers are familiar with common security pitfalls and are aware of best practices in API design.
The Good News
While this seems like an endless list of things to be aware of and believe me I have only covered the big issues and in very broad strokes, there is hope.
Modern security libraries are under constant audit, and there are tons of services you can use (like identity servers) that will put the security concerns in other people’s hands.
Cloud computing (Azure, AWS, Google Cloud Services) provides more reliable servers that you no longer have to worry about patching constantly. While not perfect, they do provide some default security for denial of service and SQL-injection attacks.
And finally, there are plenty of free (and paid) Penetration Testing Tools and companies that specialize in making sure your API is at least safe from automated attack.
