Demystifying API Security

Dhananjay Bapat headshot
6 min read

APIs are key vehicles for organizations to collaborate internally, within departments, and externally, with customers and partners. Organizations also rely on a number of third-party APIs, created by partners or public entities. However a recent survey of enterprise customers revealed that a large percentage of internal APIs and as much as 25% of third party APIs are not managed in any way. Without an access control or governance layer in your API strategy, you and your organization are vulnerable to data theft, financial loss, loss of intellectual property, and a hit to your reputation. In fact, 66% of security incidents reported can be traced back to unsecure APIs.

But securing your APIs is actually a relatively simple task. SnapLogic API Management solution, which is tightly integrated with the best in class iPaaS platform for Data and Application integration, allows you to effectively manage and govern your internal and external APIs. In this post, I will cover various security policies you can use within the SnapLogic API Management solution. 

Here is a list of policies that SnapLogic API Management offers. The list goes from the most open – ‘Anonymous Authenticator’ to the most stringent – ‘OAuth2’

Figure 1: List of Policy types that can be applied on SnapLogic API Gateway

Here is a list of access control policies that you can use with SnapLogic API Management solution.

Anonymous Authenticator policy enables anyone to access your API. When a user sends a request without any authentication method, this policy is applied. This policy can be used when providing read-only access to an API. This policy must be used in tandem with an authorization policy that would add ‘anonymous’ as a role. And because this policy exposes your API to an anonymous user, you should combine it with a throttling policy that would prevent overloading of the API gateway. The anonymous authenticator policy tracks the IP address of the client invoking the API so that you can monitor the access and usage of the API.

Authorize by Role policy authorizes API requests based on the role specified by the client. This policy is executed once a request is authenticated (except when you are using the ‘anonymous’ role). API creators can associate this policy with specific request methods such as GET, POST, etc.

Figure 2: Configuring Anonymous Authenticator and Authorize by Role policies

API Key Authenticator policy is one of the most common methods of securing APIs and it authenticates the client with the API key used to invoke the API. The key can be passed to the API Gateway as a header or as a query parameter. API consumers have the ability to subscribe to APIs, obtain API keys, and even renew API keys from the API Developer Portal. 

Authorized/Early Request Validator policies are used to perform generic validation steps on API requests. The Early Request Validator API policy is executed before authentication while the Authorized Request Validator is executed after authorization. But in both cases, when requests are validated by this policy, you avoid the cost of pipeline execution in case of an invalid request.

Callout Authenticator policy provides another great flexible option for API developers. If they have an existing REST service that authenticates users, API gateway can call out to that external service with the key specified in the API request to authenticate the user. This allows API admins to secure access to APIs through a multi layered process. 

Figure 3: Configuring Generic OAuth2 policy with GitHub as an OAuth2 provider

Generic OAuth2 policy leverages an OAuth2 provider to authenticate a client and is emerging as one of the de facto standards for authentication. The client is redirected to the OAuth provider to complete the authentication flow. Once the gateway receives the access token, it gets an ID and assigned role for the user and the session cookie is then returned back to the client.

OAuth2.0 Client Credentials policy leverages existing client credentials from your OAuth2.0 environment to authenticate users. This policy is ideal for machine-machine authentication and used in scenarios where user-level authentication is not required.

Here are a few other security policies 

IP Restriction policy restricts access based on the client IP address. This policy can be a great way to limit certain APIs for an organization’s internal use. This policy is executed early in the request processing cycle to limit the effect of excessive requests from a client with a blocked IP address.

Request Size Limit policy limits the size of the payload that can be sent to the API gateway via the API request. If the size of the request payload is invalid or if it exceeds the threshold, the request is rejected.

Cross Origin Resource Sharing (CORS) Restriction policy allows API developers to indicate appropriate headers for requests coming from a different domain so that the request is not blocked by the browser.

Following is a list of traffic control and transformation policies.

Client Throttling policy limits the number of calls an API consumer can make in a given time frame by rejecting requests that exceed a specific threshold. This policy allows API developers to implement service tiers for API consumers. This policy configuration allows API Admins to create service tiers for various roles that enable metered access to the APIs.

Request Transformer policy transforms a request before passing it onto the remaining policies and for pipeline executions. It allows API developers to add, replace, remove parts of the header when certain conditions are met.

Another great feature of the SnapLogic API Management solution is the policy hierarchy. Policies can be applied at the org level, project/project spaces level or at the individual API version level. This feature allows API admins to set a base set of controls/permissions such as client throttling or IP restrictions that can be applied to all APIs in an org or a project. For example, having a global client throttling policy prevents any API consumer from overloading the Snaplex with too many requests. You can also have different sets of policies for different versions of APIs, giving you the maximum flexibility in creating the right governance layer and user experience for your APIs.

I hope you got a good overview of the security policies you can apply to your APIs so that you can safely expose them to internal and external API consumers. Stay tuned to this space to learn more about SnapLogic API management solution and how it can help API developers and consumers to bring API products to market faster. Can’t wait? Request a demo for our API Management solution today!

Dhananjay Bapat headshot
Sr. Technical Product Marketing Manager at SnapLogic
demystifying api security post thumbnail

We're hiring!

Discover your next great career opportunity.