Finding, fixing and preventing security vulnerabilities from entering production requires understanding the scope of what you’re protecting. When it comes to APIs, this information is often hard to get, out of date, or incomplete. Like the blind men trying to understand the elephant, the stakeholders involved with developing and operating an API understand the system in different ways. Often referred to as the “three lenses of production”, it’s important to understand the various roles and responsibilities each stakeholder plays to further understand where information overlaps and where attention to detail may be lacking.
Three Lenses of Production
When we dive into the various stakeholders responsible for understanding API attack surfaces, they fall into these three key roles: Engineering, QA, and Security. Each has their own unique role, which we’ve outlined below:
Engineers understand how code is written and the routes that exist. They often communicate in documentation such as OpenAPI specifications. Given the speed of software development, these documents can be challenging to maintain and at times, can be out of date or incorrect.
QA teams understand how the system actually works, but they usually don’t test the entirety of the API due to time constraints. They document their knowledge using automated testing frameworks like Selenium or Cypress tests.
Security teams monitor production to ensure that no one is attacking the system. They have insight into how users are using the system, but they might miss long-tail routes that get called infrequently. Their knowledge can be stored in API Security tools such as Salt Security, Tenable, or NoName.
Integrate API Security with StackHawk’s API Security Testing
If using tools like Salt Security or Traceable you can export an OpenAPI Specification based on the real API requests logged by the monitoring system. With your newly created OpenAPI Spec, you can test your website by configuring HawkScan. Note: Since you’re likely protecting your production server using an API Security tool, take care to not run your StackHawk tests on production. Make sure that you edit your tests to run against your preproduction system. If you copy URLs directly from production, ensure that the domains have been adjusted to point at pre-prod.
This process of extracting an OpenAPI Spec from your API Security system and connecting it to the testing pipeline is also something that is worth automating to connect to your API security system and extract a new OpenAPI spec whenever your scan runs. This will ensure that you are always running against a recent version of your API specification.
Understanding Your API Attack Surface: Best Practices
When it comes to comprehending your API's potential vulnerabilities, there are key steps that developers and security professionals should prioritize.
Begin by examining the API's routes and operations, as this provides a fundamental understanding of its functionality. Next, delve into the specifics of the data flowing through the API. This involves integrating this data into your testing strategy to replicate realistic scenarios.
A valuable strategy is to leverage attack data collected from your API Security tools. This data can be replayed across your entire system, extending beyond the original points of attack.
Consider a scenario where your security team detects an attempt to exploit a common SQL injection vulnerability in a user creation form. If the user creation form is utilized in various parts of your enterprise, you can efficiently assess your system's safety by applying the known attack technique across numerous API endpoints using custom data.
Build a Strong AppSec Program
When dealing with data from production systems, exercise caution to avoid transferring customer or personally identifiable information from production to pre-production environments. Adhering to corporate compliance controls is essential, and it's wise to keep sensitive data separate. Nevertheless, this doesn't hinder your ability to utilize attack data, which doesn't contain sensitive details.
Remember, the essence of shifting security left is to detect vulnerabilities prior to their introduction in production. While API Security systems might not be aware of new functionalities until deployment, this presents an opportunity for enhancement. You can establish procedures that grant your team insights into upcoming or modified APIs, allowing thorough testing before reaching the production phase.
By being vigilant and proactive, you're ensuring a robust security approach that benefits both your team and the overall system integrity.
Summary
Connecting your API Security system to your API Security Testing program means that you will more fully understand the surface area of what you’re testing and can prioritize APIs that contain sensitive data. See how StackHawk stands out as one of Salt Security’s inaugural partners implementing this technique.
Dan Hopkins is VP of Engineering at StackHawk
Read more:
