IBM Developer Blog

Follow the latest happenings with IBM Developer and stay in the know.

There's a lot to think about when you're creating an API. One of the most important ways you can create a successful API is to…

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.

1. Separate your security layer from your business logic

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.

2. Authenticate your users

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.

3. Validate your parameters

An often-overlooked line of defense is parameter validation. Validating your parameters, using strict allowlists when you can, is key to stopping a lot of attacks. Accept only the values you allow, and nothing else. Most languages have robust libraries or modules for creating validation rules (check out Validate.js for JavaScript).

4. Use trusted, proven security algorithms

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).

5. Store internal data securely

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?

6. Use simple calls

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!)?

7. Implement Transport Layer Security (TLS)

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.