The Top 3 API Security Weak Spots
By Ali Cameron
The API landscape is constantly expanding. More and more, companies are leveraging APIs to better use internal and external data and create optimal experiences for their customers. APIs are also proving to be key players in driving innovation, providing the tools and information required to inspire new ideas and use cases. However, these benefits don’t come without their challenges.
The way APIs work (and all the information they request and transmit) make them particularly appealing targets for bad actors. As such, businesses that want to make the most of their APIs need to also have a robust API security strategy. The problem is, the unique nature of APIs means that it’s difficult to cover all your bases when it comes to protecting them. In this article, we’re sharing the top three challenges that can get in the way of running a successful API security strategy.
#1 A lack of accurate documentation
Given the number of APIs is always growing (today’s organizations rely on tens of thousands on average) and new use cases emerge every day, the API landscape is constantly in flux. In addition, each API can also change regularly to account for new requirements or connections required. Ideally, this means that API documentation is being updated on a consistent basis, so that any security measures and processes can be designed to account for any changes.
The sheer volume of APIs in any organization — and the regularity of the changes — makes this a near impossible task if it’s not automated. According to a recent report from Salt Security, 37% of organizations update their APIs at least weekly, and another 27% update them monthly. At the same time, however, companies have low confidence in the accuracy of their API inventory, with only 19% of the report’s respondents stating they feel very confident.
Poor or lacking documentation, paired with an incomplete understanding of the API inventory, makes it increasingly difficult to have any clarity on a company’s API attack surface. So, what’s the solution?
Some of the things security and engineering teams can introduce at the development and production stages include:
- Developing a consistent documentation requirement so that security testing can be conducted effectively
- Using machine format (e.g. OpenAPI Specification) for documentation
- Dedicating resources to building and maintaining an accurate API inventory
- Establishing a plan for identifying API changes and updating documentation accordingly
#2 Lack of consistent visibility
Another important API security challenge for companies is that they have a difficult time understanding which of their APIs expose personally identifiable information (PII). Whether you hold PII data for your employees, customers, or both, this data can be particularly harmful if compromised by a bad actor. In addition, a loss of PII data can put companies at risk of regulatory penalties, which can be prohibitively expensive. As such, it’s vital to have clarity around which APIs interact with PII and how.
Today, according to the same report from Salt Security, only 18% of companies feel very confident that their API inventories provide enough detail about their APIs and the sensitive data they handle. Meanwhile, 30% claim that they have little to no confidence. The challenge also lies in how they’re getting this information: 50% rely on developer documentation to build their understanding but, as we’ve established above, this documentation isn’t always reliable.
To gain more visibility and reduce the potential for PII exposure, teams can:
- Incorporate accurate information around the type of data used in an API in its documentation
- Set parameters around the amount of data that’s exposed in a given request in order to limit the accidental sharing of sensitive information
- Use mediation tools like API gateways to improve visibility and pair them with API security tools that provide deeper API context
- Continually authenticate and authorize to ensure only the right people and systems have access to the right information
#3 Business logic gaps
When it comes to DevOps, there has been an ongoing shift left in terms of introducing security earlier in the development and production lifecycle. However, while there are many benefits to this transition, it doesn’t go far enough in terms of protecting APIs.
APIs can sometimes risk having business logic flaws that open the door to security vulnerabilities — no developer writes fully secure code every time after all. The problem is, standard pre-production testing isn’t designed to uncover these vulnerabilities. As such, code might pass a security review, but then be open to attack once it’s in production and invite bad actors to deploy low-and-slow attacks that exploit that business logic gap.
To mitigate these concerns, there are a number of things companies can do:
- Create a culture of security, prompting engineering teams to leverage secure coding and configuration practices for building and integrating APIs
- Conduct design reviews that account for business logic gaps
- Beyond security testing, take time to analyze APIs and conduct fuzz testing in runtime to uncover exploitable code
A robust API security strategy needs to cover all the bases
Most companies that leverage APIs as part of their business strategy are still in the early stages of defining what their approach to securing them is. To be truly successful in their API security strategy, it’s vital that they take the time to understand the entire attack surface and choose tools and practices that help reduce their exposure.
Ali Cameron is a content marketer that specializes in the cybersecurity and B2B SaaS space. Besides writing for Tripwire’s State of Security blog, she’s also written for brands including Okta, Salesforce, and Microsoft. Taking an unusual route into the world of content, Ali started her career as a management consultant at PwC where she sparked her interest in making complex concepts easy to understand. She blends this interest with a passion for storytelling, a combination that’s well suited for writing in the cybersecurity space. She is also a regular writer for Bora.