Application Programming Interface (API) security monitoring and testing is quickly emerging as a top priority that the C-suite refuses to keep on the back burner any longer. According to a recent report, API-focused attacks increased by 400% in the first six months of 2023. However, there are many tools and processes available today to help grapple with this increasing challenge. According to a new survey, less than 50% of organizations have API security testing tools in place, with just 29% utilizing API discovery tools, indicating that there is still much room for improvement in how we develop, protect, and secure our endpoints.
The best opportunity to get ahead of API security issues lies in the ability to identify and resolve vulnerabilities in the development stage. Shifting security left is becoming a serious conversation within most organizations, as they are beginning to recognize the need for early and continuous security testing. 48% of C-level executives have stated they are prioritizing API security efforts to protect their organization and customer’s data against the growing number of API-focused attacks.
Where Does API Security Often Go Wrong?
The most common mistake I see organizations make is considering API security testing too late. Many companies prioritize stopping attacks by monitoring APIs in production for malicious activity, but that reactive approach relies on vulnerabilities being discovered and potentially exploited in the wild. Not to mention that is when remediation is the most time-consuming and expensive.It is a good security measure to have in place, but a more effective approach begins at the design phase and involves testing APIs for vulnerable code throughout the development lifecycle in addition to monitoring for attacks once deployed. Early in the development process, teams should incorporate secure coding practices and testing mechanisms to ensure that all input is validated, authorization mechanisms are effective, authentication and password management are deployed, and logging best practices are followed. Implementing these practices at the onset will help eliminate vulnerabilities at the source when they are easiest to fix.
Organizations also tend to overlook the effectiveness of testing the running application to see how APIs behave against malicious inputs. Many API vulnerabilities are logical in nature and must be exercised to find the issues at hand. Static code security solutions such as SAST will not help in this situation; testing pre-production applications at runtime is something only modern DAST solutions can perform.
What Makes APIs So Tough to Secure?
Based on what we know about recent API attacks and current developer activities, vulnerable API surface areas are expanding. Software teams are accelerating development, and more companies are adopting SaaS applications that rely on the public internet, allowing for more interconnected systems to affect each other. This new interrelated web of APIs is causing attacks to become more complex, as data from one API can get you farther down an attack chain in another, as we saw in the Twitter breach. One little piece of data here helps extract another little piece of data there until the combination completes an exploit.
Authentication was once used as a control mechanism for data type attacks, but we are now seeing it used as a malicious tool. Salt's API Security report found a significant increase in attacks from bad actors who maliciously executed the proper authentication, making attacks harder to detect as they appear to be legitimate users. Very few APIs are left unauthenticated these days, considering that their main purpose is to make it easy for users to onboard and gain access to the data/service that an API provides. However, authentication is not foolproof and is still susceptible to simple injection-type vulnerabilities.
The growing gap between rapid API development and AppSec resources only adds to the challenge. A 2022 survey by 451 Group Research reported the average enterprise has more than 15,000 APIs in use, yet there are hundreds of thousands of cyber job vacancies across the US. The quick release cycles and agile processes we have adopted prioritize speed but inadvertently sideline comprehensive security testing, leaving vulnerabilities undetected until exploited. This is why engaging security early in the design and development process is important. Effective API security measures require thought and strategy, meaning security teams need more visibility during pre-production phases to allocate their efforts toward complex business logic testing and advanced threat assessments instead of constantly playing catch-up with existing APIs.
Best Practices for API Security
The good news is that many processes and tools exist today that have been proven to aid in preventing and stopping API attacks.
While it is understandable that more organizations prioritize the latter, stopping attacks, it is important to remember that the process of stopping attacks can begin at API inception. Shifting security left results in stopping attacks by putting in effort to prevent them in the first place. Planning and testing security measures early and often allows for API security issues to be addressed before they become a threat.
Below are a few best practices organizations can use to uplevel their overall API security posture to protect their organization and customers.
- Engage Engineering in Security Best Practices: Foster collaboration between security and engineering teams to integrate security considerations into API design, development, and testing. This ensures that security is embedded in the development process, minimizing vulnerabilities from the very start.
- Utilize Code-Generated Documentation: Code-generated API documentation that accurately reflects the API's functionality aids in testing by helping developers and security teams understand how the API is intended to work and be able to identify deviations from expected behavior.
- Integrate Early Security Testing: Security testing is a continuous process that belongs in the pipeline alongside unit and integration tests. This allows for automated security assessments throughout the development lifecycle, enabling teams to catch vulnerabilities before they reach production, and remediation costs skyrocket.
- Test Applications at Runtime: Testing how APIs act upon input can only be tested by trying inputs and checking how the output behaves at runtime. The primary capability of DAST solutions is to send various iterations of data to an input and check its outputs for responses that might indicate a vulnerability, a perfect match for API security testing.
- Developer Enablement: Equip developers with contextual information about security vulnerabilities, including detailed explanations and steps to recreate issues. This facilitates quicker resolutions and promotes a deeper understanding of security concerns.
- Allocate AppSec Resources for Complex Testing: Optimize the security teams' effectiveness by allocating their efforts towards complex business logic testing and advanced threat assessments. Automating routine security tests and enabling developers to find and fix security issues can offload repetitive tasks, freeing up AppSec resources to focus on complex business logic testing and advanced threat assessments.
API security is challenging organizations to adopt more robust defense strategies, due to the rapid pace of development outpacing available security resources, leading to overlooked vulnerabilities. Organizations can make API security more attainable by encouraging a more interdependent relationship built on collaboration between security and engineering teams, utilizing code-generated API documentation for accurate testing, integrating security tests early in development pipelines, providing developers with contextual vulnerability information, and automating routine security tasks. This approach enables a proactive security strategy, minimizes vulnerabilities, and allows security teams to focus on complex testing, enhancing the organization’s overall API security posture.
