Developing Best Practices for API Security
APIs are pivotal to the overall success of a digital transformation. They allow developers to work across the digital assets and across multiple systems with ease. More organizations are adopting API initiatives, and are approaching digital transformations with an API-first attitude, according to a report from Google.
“Some 58% say top API initiatives emphasize speeding up new application development; 47% include creation of a developer platform among their core API projects; 32% are using APIs to develop B2B partner programs; and 10% are focused on monetizing APIs to unlock new revenue streams,” the report stated.
But with increased use of APIs comes increased security risks, largely because developers struggle with API security for mobile use. One major reason is that too many developers don’t follow security best practices in the design and development phases.
Two Levels of API Security
To create best practices for API security, developers need a better understanding of where the organization’s specific security pain points are. Sam Rehman, chief information security officer, EPAM Systems, said in an email interview that there are two specific areas to consider when thinking about and developing an API security best practices list: the strategic/design level and the tactical level.
“From a strategic/design level, APIs prioritize access and reusability,” Rehman explained. “It allows others to take advantage of what has already been built without reinventing the wheel. Then, they can build on top of what has already been tested, scaled out and, hopefully, properly managed.”
API designers want to create flexibility to enable API use for various purposes, so they focus on providing as many features and access points to the core functionality as possible. The design of the API also has to take into consideration the constant changes and upgrades necessary to deliver new features.
“Although this flexibility benefits many, it also creates an opportunity for attackers to exploit the system by using factors like multiple entry points and the large attack surface, for example. At the strategic and design level, flexibility and opportunities for attack act as opposing forces,” said Rehman.
At the tactical level, factors like volume, chattiness, data leakage and bi-directional authN are areas that can cause difficulty in implementing security.
Recognizing Threats
To improve security in APIs, developers also need to know what types of threats must be addressed. Rehman offered a list of some of the biggest threats to API security; adding as a caveat that this list is hardly comprehensive.
• Weak authN and authR—Weak authN is something seen frequently, especially when it’s service-to-service. API keys should act as just one of many layers—never as the only measure. They must be rotated, and the life cycle needs to be managed tightly. Access tokens should be short-term and challenged often. Lastly, access should be granted from the bottom and promoted only when needed.
• Impersonation/credential stuffing, bots and ghost accounts—Cyberattack methods like credential stuffing and ghost accounts are a clear and present concern for online e-commerce providers but really apply to any API/SaaS providers.
• Smart scanners—There are many active and readily available scanners at the API level, giving attackers more options and increasing the search speed for an angle of attack. There are many smart scanners using context and machine learning (ML), making the attackers’ job more and more productive.
• Inside-out-only perspective—Most APIs are still tested and designed from an inside-out or defense perspective. For an API to be its strongest, it needs to be viewed from the user—and more importantly, the attackers’—perspective.
• Device security—It’s important to know who the API is talking to and determine their visibility. A secure channel is a must, but if a mobile device is wide open and has bad software with privileged access, the attackers can easily perform data exfiltration or hijack calls.
Best Practices
Knowing the security pain points in the development life cycle and the threats that need to be addressed, developers can then begin to build a list of best practices. Security best practices will always be determined first by the organization’s needs and interests, but there are a few that Rehman believes are crucial for all developers to follow, such as:
• Secure identities clearly, combine role-based access control (RBAC) and start enhancing with ABAC to fine-tune your controls/authR.
• Have smaller and more context-driven calls, ensuring that the defense layers can be more effective against attackers and reduce the impact of attacks.
• Consider zero-trust principles.
• Limit the API calls exposed, move callers to new APIs and actively monitor and sunset unused calls. Developers can also do device checks and binding to subsets and versions of calls when possible.
• Review API designs with offensive/white hat security experts to help find gaps. To test functionality, they should complete both black and grey box testing.
API security is hard. There are no standards to follow, and the uniqueness of each API needs to be taken into consideration. But understanding where the security pain points are and developing a best practices standard, security doesn’t have to be an afterthought.
