July 14 2022 | 4 min read
Technical | July 14 2022 | 4 min read
It takes a lot of development time, quality assurance, and bug fixes to deploy a fully functional API. What most development teams skip is the security and risk management necessary to ensure the safety of customer and corporate data after deployment. In many development teams, security of the API is left to monitoring, logging and future penetration testing. Unfortunately, this leaves the API vulnerable to attackers who can find exploits before you do. Instead of leaving security to after-deployment strategies, a “shift left” approach incorporates security scanning into current development lifecycles and has shown to be much more effective at reducing risks.
Deployment velocity (speed) is often a priority in enterprise API development. While rapidly deploying features to an API is important, developers might sacrifice security for speed, which leaves endpoints open to common exploits. This can be especially dangerous for organizations that process and return sensitive data using public-facing APIs.
Because developers will often skip important security controls, tracking and monitoring multiple code changes to a corporate API is a challenge for AppSec and DevOps security teams. Penetration testing and vulnerability scanning might be an added step in API code deployment, but manually performing security validation can often lead to oversights. Instead of relying on manual vulnerability scanning which is hard even on finding the relevant code changes, automation is necessary to help security teams monitor changes and automatically find potential risks.
To effectively monitor security of APIs, you need to take the necessary steps and know what to look for in API code. Here are a few common security steps you should take prior to API code deployment:
To help stop common security vulnerabilities in code, many organizations implement a static application security testing (SAST) tool. These tools will scan code as the developer creates it. It displays a warning to the developer when code is found to be vulnerable and explains how to fix it. While these tools also have their benefits, they cannot account for poor business logic that could open the application to vulnerabilities that aren’t simple to detect. SAST tools find coding mistakes but lack context which is crucial for the prioritization process in which organizations spend significant amounts of development and application security engineers man-hours. Complex business logic which is not taken to account could leave the application open to undiscovered vulnerabilities.
The biggest challenge for SAST is context. A local API is not the same as serverless cloud-native functionality. As a matter of fact, cloud-native and cloud-hosted applications are commonly misconfigured, and a SAST is unable to detect these vulnerabilities. WAFs are also incapable of finding cloud misconfigurations, and these issues have been the reason for several large data breaches.
Cloud misconfigurations can be anything from poorly designed authentication and authorization controls, infrastructure settings that allow anyone to read sensitive data, missing monitoring and logging that could be used to catch ongoing attacks, and several more. You could run a SAST while coding your application, but it would not catch any of these issues before deployment. A WAF would not catch these issues either, which means that you either perform your own review on cloud configurations or hire a third party to review your configurations in the future.
Another common issue is third-party libraries and software development kits imported into your codebase. These libraries could have intentional vulnerabilities, or they could be compromised without the third-party developers knowledge. These tools must also be scanned and any developer security announcements monitored for the latest security patches. The patches must be installed as soon as possible, but you need to first know that they exist, adding to more overhead for your development team.
A shift left approach is more important than ever to secure applications before they are deployed to production, but most environments are complex with several moving parts across cloud and on-premises systems. Because of this complexity, automation should be built into your shift left security approach to help eliminate human error and reduce overhead.
Automated monitoring embedded into your API development process is the most efficient way to detect code design flaws, secrets hardcoded in your codebase, and vulnerabilities associated with API configurations. You can integrate this automation into your standard CI/CD pipelines so that you monitor any configuration changes for vulnerabilities before every deployment.
With Apiiro, you can discover API components vulnerable to misconfigurations, code logic flaws, and the common coding errors that leave your applications open to exploits. Our tools also help you automatically remediate many common issues so that your developers can focus on coding instead of fixing security bugs.
Remember that a change to API code isn’t the only vulnerability that could lead to a data breach. Several system variables, gateways, and cloud configurations are also possible vectors.