The security for APIs means security behind the applications and integrations that depend on them, making API security a top priority for enterprise organizations today. Security is much more than encryption and requiring keys for APIs, and there are a number of proven approaches to making sure APIs are consistently secure no matter what team is producing or consuming them, using machine-readable collections.
Collection folders allow for not just the organization of API security requests, but also the execution of scripts that help set the stage for requests being made within a specific folder group, but then also do some housekeeping, aggregation, and other activities after a group of security requests have been made against APIs. When it comes to security testing, collection folders provide us with ways to logically group requests based upon the type of security test being applied, and in which order, but when it comes to the voodoo that often occurs as part of the manipulation of APIs behind web and mobile applications, these folders also allow us to get very creative in how we automate what we are going to be throwing at our APIs as part of security testing.
- Authentication - The consistent application of standard authentication as part of a standardized API management layer strikes a balance between access to digital resources and ensuring that undesirable actors do not have access to valuable assets.
- Pre-Request Scripts - Scripts that execute before a single request is being executed, allowing for the automation of configuration, authentication, and other relevant tasks that need to run in the moment before a request to an API is made, allowing for more customization and orchestration to occur before each individual request is made, helping improve testing, security, governance, and other types of areas of operating APIs at scale.
- Post-Request Scripts -
null
Each individual API request included as part of API security testing also has its own pre-request, but also post-request test script that adds an automation layer to API security testing. Each collection request can represent any possible API request being made via HTTP, making it a perfect vehicle for executing API security testing by leveraging the scripting layer present with each request for security-specific attacks. Collections can be used to develop very generic API testing using common threats as defined by OWASP top 10, or they can be used to craft very specialized and domain-specific security testing that can then be shared, forked and automated by API developers as part of operations. Opening up the opportunity for collections to be defined by security professionals, but then executed as part of operations by average developers, quality, operations, and other types of team roles.
- Authentication - The consistent application of standard authentication as part of a standardized API management layer strikes a balance between access to digital resources and ensuring that undesirable actors do not have access to valuable assets.
- Pre-Request Scripts - Scripts that execute before a single request is being executed, allowing for the automation of configuration, authentication, and other relevant tasks that need to run in the moment before a request to an API is made, allowing for more customization and orchestration to occur before each individual request is made, helping improve testing, security, governance, and other types of areas of operating APIs at scale. null
The response and results of API security tests can be visualized using test results and runner views, but also rendered in more custom ways using the visualizer pane. Test results can also be published to another location via API, aggregating security results across many different APIs, allowing reporting by API, team, and domain. Responses for security tests provide us with a rich way to understand the security of our operations, focusing on a single API, or if tested and monitored properly, see API security at scale across operations.
- Post-Request Scripts -
null
Having API security collections defined as collections opens up two distinct ways that you can then automate API security. First, you can schedule security tests to run on a schedule from multiple cloud regions, helping evaluate security across APIs in an ongoing way. Next, you can also bake API security into the build process by running collections as part of CI/CD pipelines, adding security testing alongside contract, integration, performance, and other types of testing already occurring here. Security defined as collections allow us to make security much more modular and executable, and something that can be manually run by any developer, but also made a required part of moving APIs from design to production, ensuring that the same level of security is being applied across APIs, no matter which team is developing them.
- Runners - Acknowledge that some collection applications will be manually run by different team members using runners, organizing different types of integrations and applications by workspaces and letting different stakeholders manually put them to work.
- Monitors - Monitoring any process across API operations defined as a collection, then bundled with any environment, setting a schedule for the execution of the collection, and viewing or publishing of the results to any other location, providing a very wide definition of what monitoring can mean across API operations.
- CI/CD - Operating in a state of continuous integration and continuous deployment involving APIs, ensuring that the process involved with consuming and producing APIs are as reliable, high quality, and resulting in consistent outcomes that benefit everyone involved, and powers useful applications. null
When API security is defined as collections it provides a standardized set of outputs that when run as monitors can be natively reported upon and piped into existing APM solutions. by tapping into the outputs provided by API security collections you can increase the observability for each individual API, but also across teams, domains, and potentially offer 100% observability for all APIs used within an organization. Collections can map to any API, but then provide authorization, scripting, visualization, and integrations we can tap to make sure our API operations are more observable, providing us with the awareness we need to steer the enterprise ship in the direction we want to head.
- APM -
- Reports - Visual reports that aggregate data from across operations, making APIs and the operations around them something that team members can see activity, history, and other dimension of what is happening across API operations, allowing different views to be organized and presented via dashboards. null