Join us for Code @ Think 2019 | San Francisco | February 12 – 15 Register now Limited availability
By Dmitriy Beryoza, IBM X-Force Ethical Hacking Team September 17, 2018
There’s a lot to think about when you’re creating an API: you have to understand what your users need, decide which datastore (or datastores!) is the right fit, create documentation (with an OpenAPI spec, of course, set up automated testing … the list goes on!
One of the most important ways you can create a successful API is to design it with security in mind from the start. In this blog post, I share 7 things you can do to ensure the APIs you are designing are secure.
One of the most important things you can do is separate your security layer from your business logic. Think of your security as the frosting on your API cake: it covers it completely and exists between each layer as well. If your security is lumpy, baked into different endpoints or the underlying functions, it’s easy to overlook (and leave vulnerable) important parts of your API. Using an API gateway (such as IBM API Connect or Kong) is a straightforward way to create a security layer for your API.
This might seem simple, but you need to authenticate users properly before they can use the API call. Once the user is authenticated, check out their permissions profile to ensure they’re authorized to make the call.
While you’re checking out validation libraries, remember that using proven, peer-reviewed standards is a pillar of secure coding. Implementing your own encryption, authentication, or communication protocols can (and often does) lead to disastrous outcomes (not to mention being a waste of resources).
Validation helps for external data, but you should also make sure important internal data—especially sensitive code, keys, or passwords—are always stored properly. Don’t rely on security by obscurity: they will be discovered. Similarly, make sure your debug and test code is removed in production. Attackers love to find debugging endpoints, special calls used for troubleshooting, or other backdoors, and will exploit them. What would happen if someone with bad intent read all your source code? What else could they do or access?
Even legitimate access to your API can cause significant trouble if calls are too powerful. Make your calls as weak as possible—in a good way!—by limiting their functionality to the bare minimum required to get the job done. RemoveFile() is a much safer call than callOSCommand(). Can someone DoS your application by sending huge inputs that overflow your memory or disk, or by requesting a file export or a database backup a few hundred times in a row (a real-life example!)?
Remember that authentication and authorization aren’t secure if your communications aren’t secure. Use TLS for all communications and block downgrades to unsecured communications (or older, vulnerable versions of SSL/TLS). Consider implementing certificate pinning to prevent MitM attacks.
These are just a few of the things to think about when you’re designing security for your API. In addition, you should always spend some time threat modeling. What does it mean to “threat model”? Think like an attacker, and imagine all the ways they could use your API to hurt your application and the system it is running on.
APIs are the plumbing of modern software development: you can keep yours running smoothly and safely by building in API security at every step of your development process.
Special thanks to Erin McKean for helping me write this blog post.
Back to top