APIs are the new frontier of security. The bulk of web traffic is now going to and from APIs. Of course, some APIs are built extremely securely while others have no security implementation at all. API security has long been a blindspot for many developers and organizations and this is beginning to catch up with those who have foregone proper security measures. Many developers have just simply not protected their APIs against the possibility of an API attack.
API security is complex because there are both proactive and reactive ways to handle it. Many companies have hopped on board with the reactive approach to monitoring APIs and dealing with any issues as they happen or after they do. Less have adopted the idea of moving API security earlier in the SDLC to tackle things more proactively.
Let’s dig into the different aspects of API security including what it is, why it is important, and some helpful tips on how to improve your organization’s API security protocols.
What is API security?
API security is making sure that APIs are built with security best practices in mind and that deployed APIs require authentication and authorization for access. Sounds quite simple but API security becomes very complex, very quickly. There are many angles from which API security can be interpreted.
In the design and build phase, API security means using secure coding best practices. This means writing code that does not expose or create a vulnerability. It also means being careful that third-party dependencies don’t have vulnerabilities built in that you could be unintentionally adding to your code. Creating security gaps in your application code is extremely preventable. There are many tools available to help identify and remedy them before you hit production. In the later stages of the build phase, manual and automated testing should also be performed to identify vulnerabilities potentially missed in the earlier stages. Of course, we at StackHawk suggest also adding automated testing for each code commit by adding testing directly to your CI/CD build process.
Once built, your API will be deployed generally into different environments as it moves into production. Depending on the organization, you may see something similar to development, QA, pre-production, and finally the production environment. It is highly recommended that you implement some type of API management solution to help manage your APIs as they move through each environment. API management solutions can help with security in terms of enforcing rate limiting and quotas, keeping track of API users, enforcing authentication and authorization, and much more. API management also allows you to see your entire catalog of APIs and to easily apply uniform security to all through a single platform. API management allows for a “single pane of glass” approach to monitoring and securing your APIs.
Once the APIs have been built and deployed to production, ongoing API security monitoring is recommended. Much of the time, the API security monitoring product can be connected to your API gateway so that your API analytics can be used to monitor for anomalies. API security monitoring can detect possible malicious activity and security issues within the API traffic. If an issue is detected, the tool will then raise an alert so that teams are notified and can contain and minimize the impact.
Ongoing improvement to API security should be at the forefront of all development efforts. A great way to ensure that your APIs are secure is to monitor for issues outlined in the OWASP API Security Top 10. Let’s take a look at that next!
What are the OWASP API Security Top 10?
The Open Web Application Security Project (OWASP) is a non-profit, collaborative online community that informs and educates about various security issues within web applications. They are the community behind the OWASP Top 10. Starting in 2003, OWASP has been publishing an authoritative list of the most prevalent vulnerabilities and ways to mitigate them. With the rise in the popularity of APIs, OWASP began producing a more targeted list of vulnerabilities plaguing APIs and how to avoid them. This culminated in the release of the first OWASP API Security Top 10 list in 2019.
Let’s look at each of the vulnerabilities and a brief summary straight from the OWASP API Security Top Ten.
Broken object-level authorization
APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object-level authorization checks should be considered in every function that accesses a data source using input from the user.
Broken authentication
Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other users’ identities temporarily or permanently. Compromising a system’s ability to identify the client/user, compromises API security overall.
Excessive data exposure
Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
Lack of resources and rate limiting
Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
Broken function level authorization
Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.
Mass assignment
Binding client-provided data (e.g., JSON) to data models, without proper properties filtering based on an allowlist, usually leads to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in API request payloads, allows attackers to modify object properties they are not supposed to.
Security misconfiguration
Security misconfiguration is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
Injection
Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
Improper assets management
APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.
Insufficient logging and monitoring
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, and pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
Why is API security important?
API security is important because APIs are the driving force of much of the functionality and revenue generated by modern businesses. By letting API security go without attention, you could be inviting massive vulnerabilities and breaches into view that can be easily mitigated.
With the rise in API usage and our dependence on APIs, deploying unsecured APIs or building APIs in an unsecure manner is putting your business at a massive risk. Vulnerable APIs can leak sensitive data, allow for DDoS attacks to occur, and allow for API abuse. If an API attack were to occur, it could heavily affect the trust in your organization and massively tarnish your reputation. On top of this, there may be legal ramifications to any breach that happens from a lack of implementing the proper security measures for your APIs. API security is an important part of a sustainable business and should be one of the highest priorities, especially for those businesses that have public APIs that are easily accessed.
How to secure your APIs
Securing APIs takes many different forms. The angles to cover API security include when the API is designed and built through to when they are live in production. Many different tools can be used for this including using static code analysis dynamic application security testing tools, fuzzing, active API security monitoring, and even manual testing methods.
Building secure APIs early in the SDLC
Early in the software development lifecycle, automated security testing can be implemented and put on autopilot. There’s also an opportunity at the start of a project or with the addition of any new code to ensure that secure coding practices are put in place.
Secure coding practices include making sure that all input is validated, authentication and password management is put in place, session management is implemented and enforced, and error handling and logging best practices are followed. There are many other factors that also can be looked at to ensure code is being built and deployed securely. Making sure that these standards are enforced against any new code written can help stop vulnerabilities at the source. Keeping developers aware of these practices from the start also leads to less refactoring later if vulnerabilities are found by other tools.
One example to dig into is error handling and logging. Developers should not disclose important details that could be used to create an exploit more easily through the error handling and subsequent logging implemented in their code. This includes allowing errors to display system details, session identifiers or account information. You’ll also want to ensure that developers are not printing out debugging or stack trace information which can be viewed publicly. By setting these expectations and rules with developers, everyone who is contributing code will do so in a more security-conscious fashion.
API security also involves making sure that the infrastructure behind the APIs is secure. This means making sure that servers and databases are hardened and require strict access control for those who do have access. Another factor is making sure that all infrastructure is running the latest security patches and recommended operating systems. On top of securely built code, making sure that your infrastructure is secure reduces the possibility of exploits.
Of course, it makes sense to also include automation in your efforts early on as well. This will likely include a SAST and a DAST tool to scan and make your team aware of potential vulnerabilities.
Static application security testing (SAST) is a white-box testing methodology. A SAST tool scans your source code and related dependencies, the frameworks and libraries your application uses. During the scan, the tool refers to a predefined set of rules to detect issues and vulnerabilities, marking their exact location.
Dynamic security testing (DAST) uses a black-box approach that assumes no knowledge of the inner workings of the software being tested. This means that the DAST tests only use the available inputs and outputs for the system or API. DAST tests are dynamic since the number of inputs and outputs increases and decreases, and the data they consume or release continuously changes.
The main difference between DAST and SAST is in how they approach security testing. SAST scans the application code at rest and can be done at any point, even if the code is not ready to run. These scans discover faulty code which could be exploited. DAST tests the running application and has no access to its source code meaning that the application must be built and deployed. The DAST scans generally tend to bring back fewer false positives than SAST. This is because the existence of an exploit can be confirmed to exist more accurately versus generic pattern matching of static code analysis. Combining both SAST and DAST testing tools can be a great way to ensure a high likelihood of catching any security flaws before they reach production.
This should set most organizations up with a very robust security framework to make sure code is being generated in a secure fashion and tested robustly.
Testing before production
As code moves through your company's SDLC and processes, it will likely reach more than a single environment before getting pushed into production. It is a good practice to also test once the code leaves the development environment. In the QA or testing environments, manual API testing can help to uncover bugs that may not have been revealed by automation. It’s also a good practice for vulnerability fixes to be retested at this stage to ensure that any potential exploits are unable to occur in production.
As vulnerabilities are discovered in higher environments, code should be moved back through dev to ensure that the automated tests have a chance to discover any additional bugs introduced by fixes. If this is not possible, it would be recommended that all automation implemented in the lower environments be moved into each environment where code fixes are applied and tested. Following these practices should lead to good code quality and a reliable production deployment without any major security vulnerabilities.
Monitoring APIs in production
Lastly, once the code hits production you’ll want to implement robust monitoring practices. As secure as the code should be, it’s always best to have some type of monitoring to alert your organization of potential attacks and threats. By implementing real-time security monitoring, you can be assured that any runtime exploits that are occurring will be detected and your team will be notified immediately.
Working with your security team and using the tips above can help to create a highly secure API development and deployment framework. All aspects from development to the running production code are important and should not be understated. Many tools exist to easily implement the security practices mentioned above. Adding these tools can help to reduce development timelines and make for an easy-to-manage security standard throughout the SDLC.
Using StackHawk for API security
As mentioned above, DAST tools can be a major help when trying to uncover vulnerabilities in running code and APIs. With StackHawk you get a best-in-class DAST solution which brings automation, easy configurability, and robust testing to your code. With StackHawk, creating your API security testing configuration can be done in many different ways. One way is to run a scan to crawl your application and identify endpoints, although this can be rather inconsistent and miss API endpoints. For more complete and explicit testing, you can use an OpenAPI spec to define all endpoints as well as the expected input and output of your APIs. StackHawk also allows you to test API authorization and authentication to ensure sensitive data is protected and access control is working as anticipated.
On top of RESTful API support, StackHawk also supports GraphQL APIs, through the use of an introspection endpoint, and SOAP APIs, by uploading a WSDL to identify services. You can also use a Postman Collection to identify endpoints and add them to your security scan. Going beyond traditional API security testing tools, StackHawk allows you to support your legacy APIs and technologies as well as the latest and greatest.
To get started with API security testing and StackHawk, your first need to sign up for a StackHawk account. After you have signed up, you’ll simply need to:
Add the StackHawk config file to your project’s repo. The config file will link out to OpenAPI Spec, GraphQL introspection endpoint, Postman collection, or any other inputs used to inform the scan of your available endpoints.
Add the StackHawk scan to your setup. This can be done via the StackHawk docker container or StackHawk CLI tool. This can be added directly to your CI/CD pipeline to enable testing directly within your GitOps flow.
From here, you can start catching API security issues as they are introduced into the codebase.
Once these steps are complete, you’ll have a robust DAST tool added to your organization's security toolbelt. Combining StackHawk with a SAST solution, like Snyk, and an API security monitoring tool, you can be sure that you are building, deploying, and running your APIs in a secure fashion.
Wrapping up
In this article, we chatted about all things API security. We touched on what it is, the top vulnerabilities to look out for, and a few ways to create a robust API security framework. Although never easy, API security is seeing a massive shift in accessibility and availability. One such tool helping to put better API security in the hands of developers and reduce security risk is StackHawk. StackHawk’s DAST platform is helping organizations to build better and more secure APIs earlier in the development lifecycle. Sign up today to get started with the only DAST and API security testing tool that runs in CI/CD, enabling developers to quickly fix security issues before they hit production.
