If one were to narrow down the most important considerations of a successful API design, security would definitely be one of them. Both developers and end users want a guarantee that the service they’re using will handle their data safely. Without the promise of security, all other elements of the API design fall flat. That’s why, when designing an API, you will need to make security a part of the formula.
To that end, this article will help you review some core principles about keeping information safe when designing an API. These will be paired with some security best practices that you can incorporate into your own API design workflow. Read on and learn how to design a solid, safe, and easy-to-use API.
Protecting Information in Computer Systems: A Recap in the Context of APIs
When it comes to the design of computer systems, there’s a set of security principles that everyone can refer to. Jerome H. Saltzer and Michael D. Schroeder released the tutorial paper “The Protection of Information in Computer Systems” all the way back in 1975. But to this day, the principles mentioned in the paper remain relevant to security-oriented computer system design. Here are some that may apply to API design.
The Principle of Least Privilege
Whoever is using the API must have only the permissions for actions that they’re authorized to carry out and nothing more than that. The permissions can be expanded as necessary but should also be revoked when they are no longer in use.
The Principle of Fail-Safe Defaults
By default, the API user’s access level to any resources in the API should be denied unless they are given explicit permission.
The Principle of Open Design
The API system is ideally built using open design which is free from ambiguities or secret algorithms. That’s why following an OpenAPI design is generally the way to go.
The Principle of Separation of Privilege
Whatever permissions an API user has, it’s best if they’re not based on single conditions. The safest route is to apply multiple conditions for access.
The Principle of the Least Common Mechanism
In the case of REST APIs, or APIs that use the representational state transfer architectural style, different components should not share states. If something corrupts that shared state, then the rest of the API’s components will come crumbling down.
Design Your API for Optimum (News - Alert) Security with These 8 Best Practices
Now you understand how the principles of protecting information in computer systems apply for APIs. Here are some tips that can help you put these into practice.
Take Advantage of the Simplicity of REST API Design
Part of what makes REST the industry standard for web APIs is its simplicity and straightforwardness. This also contributes to the API design’s overall security. The less complicated your design is, the fewer holes you’ll leave in it. Ultimately, this means that there’s less leeway for security issues to come to fruition.
Keep Your REST API Stateless
REST should also enable you to keep your API stateless. As a consequence, both request authentication and request authorization are not dependent on cookies or sessions. Statelessness, then, should make the API more secure to use.
Put Multiple Authentication Layers
An authentication layer is meant to determine the user’s or the client’s identity. It helps provide evidence that the right person has the right permissions to your API’s resources. Design your API with multiple layers of authentication, so it is not easy for unauthorized users to bypass the system.
Hash Passwords
When a password is hashed, it’s inputted into your API as a scrambled representation of itself. Only the user’s hashed password, and not the actual password itself, is stored in the system. The one-way hashing will prevent the password from being “unscrambled” by a malicious agent if the latter suddenly gets access to it. This is one of the most reliable ways to protect some of the most sensitive info that goes into your API.
Encrypt Everything
Another thing you should incorporate into the API’s design is encryption. Use cryptographic protocols to encrypt the API’s communication flow. That way, you will worry less about the authentication credentials being handled by your API, such as API session tokens and API keys.
Prevent Exposure of User Information in URLs
In REST API design, URLs are used to address the API’s resources. Sound REST API design dictates that you write URLs purposefully. That includes making sure that the URLs don’t contain sensitive information, such as usernames, passwords, API keys, or session tokens. Don’t give hackers any room to breach the REST API’s security through its URLs.
Consider Adding Throttling and Resource Quotas to Your REST API
To better enforce your API, you may also want to consider restricting usage of resources once certain conditions have been met. You can add a cap on bandwidth, on the number of requests for a time unit, or on usage per month. You can also restrict the number of users or limit access privileges to users from a particular organization. These are good ways to insulate your API from cyberattacks like distributed denial-of-service (DDoS).
Secure the Request-Response Lifecycle through Validation
The space between the API request and response is one of the most common points for cyberattack. You should have especially tight security controls here, such as a strong validation check and swift rejection of the request if the validation fails. You can supplement these checks with informative error messages for the users, plus examples of how to input data correctly. This should also lessen any frustrations they may have with the system.
Conclusion
Some designers may worry that being very strict about the API’s security will take away from the user experience. But it’s actually just the opposite. Good security will contribute greatly to the overall experience the user has of your API.
Don’t underestimate the value of airtight security in your API design. It goes a long way in earning—and sustaining—your API users’ trust.
