Getting Started with API Security Best Practices 

In simple terms, an API (application programming interface) is a piece of software used to talk to other pieces of software. The use of APIs continues to spike with no signs of slowing down. This presents more pathways that have the potential to be exploited, especially if API security isn’t prioritized through activities such as application penetration testing. Oftentimes security for APIs isn’t part of the development phase, but rather addressed after a launch if at all. 

The growing need for securing APIs over the last five years inspired Open Web Application Security Project (OWASP) to create the API Security Top 10, a list of the top API vulnerabilities facing developers and DevSecOps today. The 2023 list was just released and concluded API1:2023 – Broken Object Level Authorization and API2:2023 – Broken Authentication have remained in the top places for security concerns since 2019, showing us more work is needed to address these core vulnerabilities. 

Knowing that more and more APIs are being used to build software, security implications need to be top of mind for all IT leaders.

API Security is the Underdog We’re All Rooting For 

Organizations require clarity on the fact that API security needs to be prioritized alongside other security domains. Traditionally, software goes through security testing as a whole, instead of testing the APIs individually. This form of testing leads to missed information and possible vulnerabilities for adversaries to take advantage of.

Typically software includes many APIs, and automated scanning tools aren’t able to provide comprehensive results. Manual testing is needed to fully understand the breadth of security implications — which is a challenge for many organizations due to time, resource, and budget constraints.

API Security versus Application Security 

API security is a subset of application security that is more challenging because APIs are harder to remember to secure, given their development process and lack of use case foreshadowing.  

When a developer is building small bits of software, like APIs, they may not be able to foreshadow how it will ultimately be used, so security can fall to the wayside. Rather, when developers build a larger software application (general applications), security professionals often automatically think of adding security controls such as authentication, input validation, or output coding. The shift that needs to happen when working with APIs is that those automatic security responses are built into the requirements to become an inherent property of the APIs.

API Security Best Practices 

The traditional pillars of AppSec apply to making APIs more secure, such as input validation, output coding, authentication, error handling, and encryption to name a few. IT security leaders need to think of these pillars and all the different ways in which APIs can be used to build out comprehensive security controls.  

In short, organizations need to build secure development frameworks with APIs that take the security considerations out of the developers’ hands – since they often don’t possess a security-first mindset – and build security directly into the APIs themselves. 

Go back to the basics. Every CISO can benefit from this practice. Just like with general software security, if you don’t go back to the basics first, you won’t be able to mature the program. Right now, the basics are where organizations are struggling. NetSPI’s 2023 Offensive Security Vision Report had similar findings. These foundational security flaws are ever-present, and we’re still challenged by the basics across attack surfaces.

Questions to Consider Before API Pentesting 

API penetration testing is conducted in a similar manner to traditional web application testing. However, there are several nuances to API pentesting that must be considered during the scoping phase. Overall consultants require engagement from API developers to ensure that testing is done thoroughly. These questions explore what is specifically needed to maximize API pentesting success – from the very beginning.

1. Production vs Staging: Is it possible to provide testers with an API staging environment? 

NetSPI recommends providing penetration testers with a staging API environment. If testing is done in staging, the testers can use more thorough and invasive/comprehensive attacks. If testing is done in production, then testers will be forced to resort to more conservative attacks to avoid negatively affecting the system and disrupting the end-users.  

2. Rate Limiting: How is rate limiting implemented on the target API? Is rate limit testing in scope for this engagement? 

By leveraging rate limiting flaws, attackers can exploit race condition bugs or rack up costly service hosting bills.  

3. WAF Disabled: Is it possible to disable the API’s WAF or allow list the penetration tester’s IP range during the testing window? 

If possible, we recommend API WAFs are disabled when testing occurs. If testing is done in production, consider allow listing your testing team’s IP range. Read more on how it adds value to API pentesting here. 

4. New Features: Are there any new features in scope that we should focus on? 

New features that haven’t been reviewed for security issues are more likely to be vulnerable than hardened code.  

5. Denial of Service (DoS) Testing: During the test, will DoS testing be in scope? 

Denial of Service vulnerabilities of APIs can have a catastrophic impact on software systems.  

6. Source Code Assisted Testing: Will source code be provided to consultants during the test? 

By providing source code, consultants are enabled to test applications more thoroughly without additional cost. For additional information on source code assisted penetration tests, check out our article on “Why You Should Consider a Source Code Assisted Penetration Test.” 

Due to their programmatic nature, APIs provide additional customer interaction during the scoping process. By providing testers with the information listed above, testers are able to provide maximum value during an API penetration test and maximize the return on investment. 

Predictions for the Future of Security API 

Going forward, we’ll likely see a software development paradigm shift over the next five years that combines features from REST and SOAP security. There is likely to be a software development paradigm where some features from each method are used to create a combined superior method – something we’re already starting to see with Adobe and Google. This combination will take security out of the hands of the developers and allow for better “secure by design” adoption. We must enable developers to innovate with confidence.

Additionally, the concept of identity and authentication is changing — we need to move away from the traditional use of usernames and passwords and two-factor authentication, which relies on humans not making any errors. The authentication workflow will shift to what companies like Apple are doing around identity management with innovations like the iOS16 passkeys, and could even impact the OWASP API Security Top 10. This will be developed through APIs. 

APIs provide incredible value with connectivity between systems. They are here to stay, making API security a much-needed focus. NetSPI’s Application Penetration Testing gives your team a proactive advantage with identifying, prioritizing, and remediating vulnerabilities in a single platform. Bring proactivity to your API security by requesting a quote today.