How To Mitigate API Risks During Development

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 the customer and corporate data after deployment. In many development teams, the 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.

Many Development Teams Skip Crucial Security Validation for Faster Code Deployment

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.

A Brief Checklist of API Security Steps

To effectively monitor the 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:

• Audit and inventory current API repositories: Before you can set up automated scanning, you must know where developers store their code
• Embed and integrate authentication into every API: Don’t implicitly trust users even if they are authenticated internally. Always embed authentication and authorization into your endpoint access controls and data management to ensure every request is validated.
• Validate all input: User-generated input should always be validated to ensure the API is not vulnerable to malicious code injection.
• Implement the principle of least privilege: The principle of least privilege is a strategy of restricting access permissions to only the data absolutely necessary for an employee to perform their daily work functions. This includes permissions on publicly accessible data.
• Always encrypt data: Data traversing the public internet or internally should be encrypted with cryptographically secure ciphers, which means using TLS 1.2 version or above cipher suites.
• Code review all new APIs: Security teams should manually review code to ensure that sensitive data is not exposed to bugs or mistaken business logic.
• Trigger penetration testing and scanning on sensitive APIs: Blackbox and whitebox penetration testing of API code helps find security vulnerabilities before attackers do.
• Rate limit endpoint calls and use session management: To avoid a denial-of-service (DoS) or session fixation attacks, security teams must work with developers to implement controls to manage who, when and how many calls can be made to the API.
• Expose endpoints to the internet strategically: If an API does not need to be open to the internet, then determine if it can be blocked entirely or make partial endpoints publicly available to reduce risk.

Common Vulnerabilities SAST Can’t Detect

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 into 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 developer's 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 first to know that they exist, adding more overhead for your development team.

Detect Misconfigurations in Cloud APIs Before Deployment

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.

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.