OWASP top 10 API threats

You're viewing Apigee Edge documentation.
Go to the Apigee X documentation. info

This document describes various approaches you can use within Apigee to address security vulnerabilities identified by OWASP. For additional approaches documented for Apigee, see OWASP Top 10 2021 mitigation options on Google Cloud.

Introduction

OWASP is an open community dedicated to helping organizations develop, purchase, and maintain trusted applications and APIs. Through the OWASP API Security project, OWASP publishes the most critical security risks to web applications and REST APIs and provides recommendations for addressing those risks.

This document will discuss approaches for protecting against common API-based attacks, as identified by the OWASP’s 2019 top ten API security threats. A common theme in the top threats highlighted by the latest list are caused by the improper placement of authentication and authorization controls, such as the reliance on the filtering of data returned by an API request within client apps, by using the anti-pattern of relying on the consuming client app to perform access control enforcement.

With growth in the API ecosystem continuing at a rapid pace, API abuses and misuses resulting in data exfiltration by attackers is unfortunately becoming one of the most common attack vectors today. Security continues to be a key priority for Apigee, with a number of new features such as Advanced API Ops, which includes security reporting and anomaly detection features. However, designing and implementing Apigee’s security features correctly is critical to reduce the likelihood of successful attacks on your APIs.

Consumer Applications should be considered untrusted, or “public”, as you do not control the platform the app is running on. Assume that any public app can and will be compromised, therefore they cannot be trusted to enforce access control (API1, API5), filter response data (API6), or safely store client secrets (API2) such as API keys or access tokens. Some recommendations emerge from examining 2019’s OWASP top 10:

  • Determine what kind of client apps will be consuming your APIs (SPA, mobile, or browser-based), and design the appropriate authentication, authorization, and security patterns.
  • Always use “public client” OAuth or OpenID Connect flows (the use of PKCE is highly recommended)
  • Think about your app’s business logic, define your OpenAPI spec first, and design your API proxies to filter all response data from the backend within Apigee. Never rely on downstream app code logic to perform this!
  • Filter all data requests containing user-specific PII to only allow data from your backend that belongs to the requesting user.

API1:2019 Broken object level authorization

Threat description

Insufficient authorization validation of an object access request allows an attacker to perform an unauthorized action by reusing an access token. This threat is caused by an improper configuration of authorization validations. Apigee provides VerifyApiKey, OAuth, and JSON Web Token (JWT) policies, which help protect against this vulnerability, yet it is critical that these policies are correctly configured to prevent this threat.

To prevent this threat, it's important that application development and security teams collaborate closely. Authorization is by nature a complex topic, and effective fine-grained authorization requires a deep understanding of the application’s business logic.

There are two main aspects to consider from an Apigee implementation perspective:

  • Access token integrity
  • Access control enforcement

Access Token Integrity

It is critical to validate that the token provided by the requesting client has not been tampered with, by using the correct OAuth or OpenID Connect flow along with the appropriate credential validation or signing mechanism. Apigee supports all the commonly used OAuth flows.

Apigee access token verification policies include:

Access Control Enforcement

Once the access token’s validity has been verified, it is critical to implement access control enforcement policies to evaluate each incoming API request against the access entitlements of the authorization token.

Apigee provides two main mechanisms for verifying and enforcing authorization policies:

  • Internal: using conditional flows to evaluate access requests based on claims extracted as flow variables from an authorization token
  • Delegated: using a service callout to a 3rd party access management solution

The internal approach (illustrated in the figure above) is recommended when the access control model is relatively straightforward. For example, if claims extracted from an access token can be used to directly evaluate and authorize an API object request.

Use the flow variables available for the OAuth or JWT policies to evaluate access requests using conditional flow statements.

The delegated approach (illustrated in the figure above) is recommended when claims extracted from an access token cannot be directly used to authorize an API request to a backend object, or for more complex OAuth flow types which require a separate call to an authorization server to obtain an access token.

Using the service callout policy, it is possible to either request an authorization policy decision from a third party service, or to obtain additional claim information about the requesting agent to then make an access control decision using a conditional flow

API2:2019 Broken user authentication

Threat description

Badly implemented user authentication policies allow for attackers to impersonate legitimate users by taking advantage of implementation flaws in authentication implementations. Some authentication principles to bear in mind when implementing authentication approaches include:

  • Always authenticate both the user agent (the app) and the requesting user
  • Use delegated authentication and authorization patterns and avoid passing passwords directly within an API request
  • Always validate the signature of access credentials, and ensure that all access credentials used have a defined expiry time
  • Prevent brute force attacks by setting quotas and using Apigee Sense to detect and respond to bot-driven brute force attacks

Under an outside-in paradigm, the API design is built around the consumers' use cases for the data rather than the structure of the existing data in your backend systems, and security is a critical element when designing APIs for external consumers. Backend systems traditionally are not built with sufficiently strong authentication implementations for exposure to public networks. This is where Apigee, coupled with an identity and access management solution, can offer strong solutions for protecting against this threat.

There are few major elements to consider here, both of which will be addressed in subsequent sections:

  • Security design: making full use of Apigee features for implementing authentication patterns
  • Governance: ensuring that the correct use of the designed authentication patterns are used consistently, across all published API products
  • Operational security: being able to detect suspicious or anomalous behaviors and attempts to circumvent or brute force authenticated API proxies

Security Design

The objective of security design is to correctly implement authentication flows and integration with 3rd party identity tools. Security design is a critical phase, and it starts with understanding the right type of delegated authentication flow to use based on the type of app that will be consuming your API endpoints. The next step is defining, along with your identity team, the integration patterns to implement with your identity solution.

The OpenID Connect and OAuth RFCs provide a broad number of delegated authentication and authorization flows, as well as actors involved in these flows. This is a complex topic, and it is unsurprising that broken authentication is one of the top OWASP API threats. Providing a comprehensive primer on the correct implementation of identity standards is outside the scope of this document, yet Apigee has many additional resources for better understanding OAuth flows, such as this ebook and webcast, and example implementation.

Authentication policies

Apigee policies that help address identity and authentication concerns include:

Traffic Management

The following Apigee traffic management features help protect against brute force attack:

  • The Spike Arrest policy, for setting an overall rolling average rate limit on an API proxy
  • Quota policies, for setting fine-grained rate limits to API proxies based on quotas defined by app keys, developers or API product quotas
  • Caching policies, for caching stored access tokens based on their defined expiry times, as well as the ability to invalidate cached credentials (for example, in a situation where a valid access token is compromised)

Governance

Security is an ongoing process, not a “set and forget” project, and one of the biggest causes of security breaches is misconfiguration. Once authentication flows, identity integration patterns, and authentication-related traffic management policies have been defined, it is absolutely critical that they are implemented correctly and consistently.

Apigee provides a number of features and tools for ensuring implementation integrity and preventing misconfiguration errors.

Role-based Access Control (RBAC)

Whether you’re a large enterprise or a small startup, avoiding misconfiguration errors starts by ensuring that only the right people and teams can access and modify API proxy configurations. API programs are supported by multi-disciplinary teams across your organization. It is absolutely essential that each team is only granted the necessary permissions for them to do their jobs as part of your API journey.

Apigee provides the features for you to manage role-based access by providing the capabilities for you to assign users to either predefined roles, or to create custom roles to suit your API teams. Correctly defining and managing role assignment is critical to enabling you to securely scale your API program. You can also use federation to integrate with your existing corporate directory, and to reduce your need to manage a second set of administrator credentials within Apigee.

Shared Flows

Shared flows allow you to define policies and resources into a reusable object that can be implemented across API proxies. For example, you might have collaboratively designed with your security teams multiple authentication design patterns based on the type of app consuming an API. An API developer doesn’t need to be an identity expert to reuse this, they simply need to know the correct shared flow to add to their existing API proxy configuration using the Flow callout policy.

Figure: Shared Flows are reusable bundles of policies and conditional logic that allows you to maintain a composite pattern.

Security Reporting

Once you’ve ensured that only the right people in your organization can modify your authentication patterns, and you’ve defined your shared authentication flows, you must ensure that API proxies developed by your API teams are using those authentication patterns consistently.

Apigee’s new Advanced API Ops feature includes advanced security reporting, which allows the Ops and security teams to easily view reports on all API proxies, and focuses on adherence to security policies such as the use of shared flows. Reporting, logging, and alerting is a key element of API security which will be discussed in more detail under API10: insufficient logging, but from the perspective of preventing broken authentication risks, it is extremely useful in ensuring adherence to your defined authentication standards implemented as shared flows.

Operational Security

Once your APIs are in production using the right authentication patterns with baseline traffic management in place, your SecOps team must also be able monitor and respond to suspicious activity, which often begins with attempts to compromise authentication credentials.

Apigee Sense

Apigee Sense protects your APIs from unwanted request traffic, including attacks from malicious clients. Apigee Sense analyzes API request traffic, identifying patterns that might represent unwanted requests. Using this analysis, you can identify clients making unwanted requests, then take action to allow, block, or flag those requests. Future features of Sense will include the ability to automatically enable ReCAPTCHA verification on suspicious traffic.

With Apigee Sense, you can protect your APIs from request patterns that include:

  • Automated behavior that blends with human behavior
  • Persistent attempts from the same IP
  • Unusual error rates
  • Suspicious client requests
  • Data crawling
  • Key harvesting and authentication brute force attacks
  • Activity bursts
  • Geographical patterns

Advanced API Ops

While Sense has been specifically designed for detecting and responding to bot-like threats, Advanced API Ops includes both anomaly detection and advanced alert definition.

Anomaly detections works by applying artificial intelligence (AI) and Machine Learning (ML) models to your historical API data. Anomaly detection can then raise alerts in real time for scenarios that you haven’t even thought of to improve your productivity and reduce the mean time to resolution (MTTR) of your API issues.

Advanced API Ops builds on the existing API Monitoring alert mechanism to add the following advanced alert types:

  • Total traffic alerts. Raises an alert when traffic changes by a specified percentage over a time range. For example, you can raise an alert when traffic increases by 5% or more for one hour, or decreases by 10% or more for one week
  • Anomaly alerts. Edge detects traffic and performance issues instead of you having to predetermine them yourself. You can then raise an alert for these anomalies
  • TLS Expiry alerts. Raises a notification when a TLS cert is close to expiring

API3:2019 Excessive data exposure

Threat description

A published API might expose more data than necessary, relying on the client app to perform the necessary filtering. If an attacker directly queries the underlying API, they are able to access sensitive data.

One of Apigee’s “outside-in” design principles for API design is data parsimony. Work with your UX designers and developers to only expose data via APIs that are needed within your app UI. Backend systems weren’t built for public usage patterns, so one of the first tasks of API first design with Apigee is to reduce the data exposed to the minimum necessary to provide a great API product for your customers and developers.

Another one of Apigee’s design principles is reusability. Security concerns aside, relying on an app to filter the data provided by an API results in the requirement to port that filtering logic across every platform you develop an app for.

From a security perspective, this threat results from delegating authorization enforcement to an app, often however on a platform or OS over which you have no control. We’ve already examined in API1 and API2 the importance of correctly implementing authentication and authorization to avoid unauthorized data access.

The next sections examine how to:

  • Rewrite requests and responses to backend services to minimize data exposure
  • Implement fault handling to prevent verbose error messages from exposing sensitive environment information to attackers about your backend services

Rewriting responses and requests

Backend systems are typically not designed for use on public apps or across untrusted public networks. Apigee Edge was designed to enable you to deploy public API products by protecting your backends from excessive data exposure.

To do this, Apigee uses three key policies:

  • Assign Message
  • Code callouts
  • Fault handling

Assign Message policy

The Assign Message policy changes or creates new request and response messages during the API proxy Flow. The policy lets you perform the following actions on those messages:

  • Add new form parameters, headers, or query parameters to a message
  • Copy existing properties from one message to another
  • Remove headers, query parameters, form parameters, and/or message payloads from a message
  • Set the value of existing properties in a message

With Assign Message, you typically add, change, or remove properties of either the request or response. However, you can also use Assign Message to create a custom request or response message and pass it to an alternative target, as described in Create custom request messages.

Complex rewriting with custom code

For complex data handling and rewriting rules whose complexity is beyond the capability of the Assign message policy, you can use procedural languages such as JavaScript, Java, or Python. You can add custom code to an API proxy and then call it from policies added to the proxy flow. Support for procedural code is designed to make it easier for you to implement complex handling of flow variables, faults, and request and response bodies.

With procedural code, you can:

  • Create or manipulate complex body values, such as request and response values.
  • Rewrite URLs, such as to mask a target endpoint URL.

Apigee Edge includes a separate policy for supported languages: JavaScript policy, Java Callout policy, and Python Script policy.

Fault handling

Apigee enables you to perform custom exception handling using a policy of type Raise Fault. The Raise Fault policy, which is a variation of the Assign Message policy, lets you generate a custom fault response in response to an error condition.

Shared Flows

Shared flows can be used to enforce standardization of fault messages. For example, the same configured policies that detect a specific HTTP error code from the backend can be used to rewrite the error response to return a generic error message.

API4:2019 Lack of resources & rate limiting

Threat description

By not implementing rate limiting policies, attackers can overwhelm the backend with denial-of-service attacks.

This is threat can be easily addressed by using the following Apigee features:

  • Quotas and Spike Arrest policies as preventative controls to place traffic limits on inbound API requests
  • Apigee Sense to dynamically detect and respond bot-driven attacks
  • Advanced API monitoring and alerting as detective controls to be alerted to DDoS attacks in progress

Rate limiting with Quotas and Spike Arrest policies

Apigee provides two policies for rate limiting:

  • Spike arrest provides a general policy, defined at API proxy level, for rate limiting the overall number of inbound requests to a backend
  • Quotas provide a granular policy tool for enforcing quota policies, either at an API proxy or at an API product level

Spike Arrest

The Spike Arrest policy protects against traffic surges. This policy throttles the number of requests processed by an API proxy and sent to a backend, protecting against performance lags and downtime, using a rolling average value definable within the policy.

Quotas

The Quota policy enables the configuration of the number of request messages that an API proxy allows over a period of time, such as a minute, hour, day, week, or month. You can set the quota to be the same for all apps accessing the API proxy, or you can set the quota based on:

  • The product that contains the API proxy
  • The app requesting the API
  • The app developer
  • Many other criteria

This policy is more granular than Spike arrest, and should generally be used concurrently with it.

Bot detection with Apigee Sense

With Apigee Sense, you can take action to explicitly allow, block, or flag requests from specific clients, IP ranges or Autonomous System organizations, based on those clients or locations exhibiting malicious or suspicious behavior. Apigee Edge applies these actions to requests before your API proxies process them. For example, an IP range or specific client exhibiting “brute guessor” behavior can be detected, then blocked or flagged.

Threat detection with Advanced API Ops Monitoring

Use a traffic alert to raise a notification when the traffic for an environment, proxy, or region changes by a specified percentage over a time range. This feature can dynamically raise an alert when traffic deviates significantly from your expected throughput, as would be the case during a DDoS attack. These alerts can easily be sent to a 3rd party logging and monitoring solution.

API5:2019 Broken function level authorization

Threat description

This threat is a variation on API1, and is also an authorization vulnerability. With this threat, an attacker is able to perform actions by sending requests to functions they are unauthorized to access. For example, an attacker might be able to modify or delete data which they are only authorized to read if an API endpoint does not validate the HTTP request verb, by replacing a GET with a PUT or DELETE. Or, by not implementing sufficiently restrictive access control on an API resource URI path, an API endpoint might allow an attacker view another user’s data simply changing the path in a request.

This type of threat highlights the value of using Apigee as a mediation and abstraction layer, as many backend systems - not being designed for public access - might by default provide a single endpoint for executing multiple business logic functions, including even high-risk administrative functionality.

The conceptual elements to reduce the likelihood of this threat are typically broken down into:

  • What is being protected? Think about your API product strategy, and implement logical segmentation of functionality when using RESTful best practices to design the paths and resources being exposed by Apigee API proxies, products and apps features.
  • Who is accessing your API resources? Define the high level personas and implement “least privilege” default access entitlements by using some of Apigee’s authentication and authorization features as outlined in API1 and API2.
  • How are your access policies being enforced? Use conditional flows and faults to validate the URL path and verb of all API requests.

Figure: This diagram demonstrates how function-level authorization would be enforced in Apigee, using scopes provided within an access token as entitlements.

Logical Segmentation with API proxies, products and apps

Apigee provides a highly flexible toolkit to enable the logical segmentation of API resources, allowing API proxies to be bundled into any number of API products, which in turn are consumed by your app developers, which are able to register apps that make use of your API products. Access policies can be defined at any of these levels.

Yet to implement effective functional authorization and segmentation, it is critical to define an API product strategy. Part of this essential and on-going process is the definition of the “who” and the “what” of your API products, by looking at your API resources from your customer’s and developer’s perspective, and then defining down to a path resource and HTTP verb level, exactly what types of requests will be allowed.

Figure: The API resources bundled into an API product can come from one or more APIs, so you can mix and match resources to create consumption tiers and authorization boundaries.

Function-level Access Control with OAuth scopes and JWT claims

While the authorization approaches considered above for API1:2019 Broken object authorization address fine-grained access control at object-level, it is just as important to address coarse-grained access control at a function level. Is the requesting user even allowed to request this URL path at all? This type of policy is often defined per user persona (customer, employee, administrator, internal or 3rd party developer).

To reduce the risk of misconfiguration, the recommendation here is to work with your security team to ensure that the assertions about the requesting user are contained within the access token, either with the use of OAuth scopes or JWT claims.

Request validation with conditional flows

At a foundational level, a REST API call is comprised of the following:

  • An endpoint
  • A resource
  • An action verb
  • Any number of additional request attributes, such as query parameters

The type of attack described in this threat is typically caused by the insufficient filtering of an API request, thus allowing an attacker to perform unauthorized actions or access of a protected resource. In addition to conditional logic allowing you to filter requests based on access tokens or claims, Apigee allows for the implementation of filtering logic based on the request itself.

Once you clearly understand and define the business logic of an API product, what functions are permitted by your APIs, the next step is to restrict any requests that fall outside this through these Apigee product features:

  • Conditional logic and Raise Fault policies to restrict resource paths or verbs at any step in a proxy flow configuration
  • JSON and XML Threat protection policies to protect against content-based attacks using malformed JSON or XML request payloads

API6:2019 Mass assignment

Threat description

Unfiltered data provided via APIs to client apps allows attackers to guess object properties via requests, or to use endpoint naming conventions for clues on where to perform unauthorized modification or accessing of properties on data objects stored in the backend.

This threat is caused when unfiltered data (typically in JSON or XML) is sent to a client, allowing an attacker to guess the underlying implementation details of your backend systems, as well as the property names of confidential data elements. The result of this type of attack could potentially grant an attacker the ability to read or manipulate inappropriate data, or in worst case scenarios, could enable remote code execution vulnerabilities.

There are two aspects typically involved allowing this type of threat:

  • The API design perspective. Never rely on application logic to perform client-side data filtering, as apps can be exploited by attackers and be considered trusted. Always design your API data schema to only expose the minimal, necessary data to enable an API service
  • The API implementation perspective. Implement data filtering and schema validation to prevent the inadvertent exposure of confidential data to a client application

From an Apigee product perspective, we provide several useful features for ensuring robust data filtering implementation of your APIs.

OpenAPI Specification filtering policy

The OASValidation (OpenAPI Specification Validation) policy enables you to validate an incoming request or response message against an OpenAPI 3.0 Specification (JSON or YAML). This policy allows you to:

  1. Design your API by creating an OpenAPI specification (OAS)
  2. Implement the necessary mediation, security and caching logic for securely exposing an API product from your backend with Apigee
  3. Validate incoming requests against the data schema defined in your OAS spec, including the basepath, verb, request message policy, and parameters

SOAP Message Validation policy

The SOAP Message validation policy allows you to validate XML-based requests, by either validating an XML message against an XSD schema, or validating a SOAP message against a WSDL definition. Additionally, you can use the Message Validation policy to confirm that a JSON or XML message payload is well-formed, which includes verifying the following in an XML or JSON message:

  • There is a single root element
  • There are no illegal characters in the content
  • Objects and tags are properly nested
  • Beginning and ending tags match

API7:2019 Security misconfiguration

Threat description

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. Attackers often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system they want to attack. Security misconfigurations can not only expose sensitive user data, but also system details that may lead to full server compromise. In addition, some other use cases for vulnerabilities for security misconfigurations may include:

  • Misconfigured TLS
  • Error messages with stack traces
  • Unpatched systems
  • Exposed storage or server management panels

There are various steps organizations can take to address and mitigate the challenges with regards to security misconfigurations which includes:

  1. Establishing and standardizing hardening and patching processes
  2. Developing governance around the API ecosystem
  3. Restricting administrative access and enabling auditing and alerting

Shared Flows and Flow Hooks

Apigee supports the concept of a shared flow which lets API developers combine policies and resources into a reusable group. By capturing reusable functionality in one place, a shared flow helps you ensure consistency, shorten development time, and more easily manage code. You can include a shared flow inside individual API proxies, or you can go a step further and place shared flows in flow hooks to automatically execute shared flow logic for every API proxy deployed in the same environment as a shared flow.

API Security Reporting

As organizations strive to develop a governance framework, Apigee provides capabilities around API security reporting which assists operation teams with the visibility they need security attributes of APIs to:

  • Ensure adherence to security policies and configuration requirements
  • Protect sensitive data from internal and external abuse
  • Proactively identify, diagnose, and resolve security incidents

Apigee Security reporting provides in-depth insights for operations teams to ensure adherence to policies and configuration requirements, protect APIs from internal and external abuse, and quickly identify and resolve security incidents.

With security reporting, security administrators can quickly understand how your API proxies are configured for security, as well as the runtime conditions that might impact proxy security. Using this information, you can adjust the configuration to ensure you have the appropriate level of security for each proxy.

API Monitoring

Apigee provides a comprehensive API Monitoring platform that complements the security reporting capabilities. API Monitoring enables organizations to proactively detect API traffic and performance issues. Apigee API Monitoring works in conjunction with Apigee Edge for Public Cloud to provide real-time contextual insights into API performance, helps quickly diagnose issues, and facilitates remedial actions for business continuity.

Figure: Apigee API Monitoring provides a wide range of tools to monitor, investigate, and act upon issues. It leverages best in class intelligence features from Google Cloud Platform.

Apigee Sense

Apigee Sense helps protect the APIs from unwanted request traffic, including attacks from malicious clients. Apigee Sense analyzes API request traffic, identifying patterns that might represent unwanted requests.

Using this analysis, organizations can identify clients making unwanted requests, then take action to allow, block, or flag those requests. With Apigee Sense, it is possible to protect the APIs from request patterns that include:

  • Automated behavior that blends with human behavior
  • Persistent attempts from the same IP
  • Unusual error rates
  • Suspicious client requests
  • Data crawling
  • Key harvesting
  • Activity bursts
  • Geographical patterns

API8:2019 Injection

Threat description

Untrusted injection of data, such as SQL, NoSQL, XML Parsers, ORM, LDAP, OS Commands, and JavaScript, into API requests can result in the execution of unintended commands or unauthorized data access. Attackers will feed the API with malicious data through whatever injection vectors are available such as direct input, parameters, integrated services, and so on, expecting it to be sent to an interpreter. Attackers can discover these flaws easily when reviewing the source code using vulnerability scanners and fuzzers. A successful injection can lead to information disclosure impacting the confidentiality and data loss or in some cases it may also lead to DoS.

Best practices to mitigate injection errors/attacks include strictly defining the input data such as schemas, types, string patterns, performing input validation, limit checks and enforcing them at runtime. The Apigee platform allows validating the incoming data using filters to only allow valid values for each input parameter.

Apigee Edge, acting as a server for the incoming API requests, checks to ensure that the payload structure falls within an acceptable range, also known as a limit check. You can configure an API proxy so that the input validation routine transforms the input to remove risky character sequences and replace them with safe values.

Regular Expression Protection policy

The RegularExpressionProtection policy extracts information from a message (for example, URI Path, Query Param, Header, Form Param, Variable, XML Payload, or JSON Payload) and evaluates that content against predefined regular expressions. If any specified regular expressions evaluate to true, the message is considered a threat and is rejected. A regular expression, or regex for short, is a set of strings that specify a pattern in a string. Regular expressions enable content to be programmatically evaluated for patterns. Regular expressions can be used, for example, to evaluate an email address to ensure that it is properly structured.

The most common usage of RegularExpressionProtection is the evaluation of JSON and XML payloads for malicious content.

No regular expression can eliminate all content-based attacks, and multiple mechanisms should be combined to enable defense-in-depth. This section describes some recommended patterns for preventing access to content.

There are several other approaches to validating input available with the Apigee platform:

Validate Content Types

Content type refers to content of a file which is transferred via HTTP and classified according to a two-part structure. Apigee recommends to validate the content types for the Request and Response using conditional logic as explained below.

API Security Reporting

As organizations strive to develop a governance framework, Apigee provides capabilities around API security reporting, which assists and gives operation teams the visibility they need to secure APIs by providing operation teams with the visibility they need security attributes of APIs to:

  • Ensure adherence to security policies and configuration requirements.
  • Protecting sensitive data from internal and external abuse.
  • Proactively identifying, diagnosing, and resolving security incidents.

API9:2019 Improper assets management

Threat Description

Insufficient environment management and environment segregation allows attackers to access under-secured API endpoints. Lack of governance safeguards also cause unnecessary exposure of deprecated resources.

This threat can be addressed by leveraging Apigee’s matured capabilities to manage the full API life cycle, allowing you to create a comprehensive governance model that enables collaboration among teams, and at the same time, apply separation of responsibilities between security stakeholders and API developers. Boundaries and controls can be configured and maintained using:

Organizations, Environments, and Revisions: Virtual and physical guardrails that guarantee isolation and a secured promotion process through runtime contexts.

Role Based Access Control: Only the necessary people on your API teams will have permissions to manage configuration changes and also the promotion process.

Audience Management for API Documentation: Once an API has been published in the developer portal, you can limit the visibility of documentation by managing target audiences.

Flow Hooks: You can enforce global policies and patterns that can be managed as privileged guardrails that cannot be modified by API developers.

Security Reporting: Security stakeholders have end to end visibility of published APIs and their supporting configuration. Adherence to global security policies can be audited and evaluated based on the risk profile for each published API endpoint.

Organizations and Environments

Configuration artifacts, users, and features in Apigee can be scoped to specific organizations and/or environments. This means that the platform has pre-built guardrails that can be placed around APIs and their supporting configuration.

Organizations: An organization is the top-level tenant in Apigee. It enables you to have full segregation for traffic, configuration, and users. As a governance best practice, you should consider having separate production and non-production organizations. This practice effectively avoids mixing production data, users, and traffic with lower environments.

Environments: APIs in Apigee can be promoted through multiple deployment states; each state is linked to an execution context. The environment context is not carried along during the promotion process, therefore avoiding exposing sensitive configuration to unprivileged users.

Revisions: Revisions allow APIs and individual features to be promoted seamlessly through environments.

Role Based Access Control

In order to mitigate API9 it is imperative to have clear definitions of and separation of duties between security stakeholders and API Developers. As previously stated in this document, Apigee has flexible Role Based Access Control capabilities that allow you to assign permissions to custom roles. For this specific threat, roles can be scoped to have limited privileges per organization, environments, or more granular configuration permissions. As a preferred practice, consider limiting privileges to change the deployment state of APIs through environments and also to make sure developers are unable to access or modify global security libraries (Flow Hooks). These limited roles will prevent unsolicited changes to global security policies that have broad coverage on both legacy and current published endpoints.

Audience Management for API Documentation

A Developer Portal is a pivotal component for the success of your API Strategy; it allows you to keep a comprehensive inventory of all documentation related to your APIs including hosts/endpoints, resources, operations, payload schemas, and more. In Apigee you can group your APIs using API Product constructs. API Products are defined by bundles of resources and operations that fall within the same business and security context (e.g. service plan, business domain, category, company hierarchy, etc.).

With Apigee’s Integrated Developer Portal you can publish API Products and restrict the visibility of published content by managing target audiences. This capability complies with a content segmentation strategy that aligns with business and security requirements.

Flow Hooks

The promotion and release processes for APIs must always include security compliance and certification processes. To be effective, API teams using the appropriate tools should be able to create guardrails that guarantee the separation of responsibilities and while maintaining agile release cycles.

Apigee allows you to elevate security governance duties by enforcing global policies through Flow Hooks. These global policies can be managed as privileged guardrails that cannot be modified by API developers, therefore guaranteeing separation of responsibilities and also promoting agility by applying default security and, by extension, providing security compliance for all APIs deployed in a given execution environment.

Figure: Privileged guardrails can be configured in Apigee through Flow Hooks and Shared Flows. Security stakeholders are responsible for maintaining security related global policies. These features guarantee separation of responsibilities and promote agile development life cycles.

Security Reporting

Security audits are meant to assess and test the security policies that are intended to protect your organization's data and business objectives. APIs are standardized public or private interfaces that need to be protected by a comprehensive and, at the same time, auditable security governance model.

In Apigee you have access to specialized security reports that help ensure adherence to defined policies and enable your security teams to take action based on comprehensive insights on:

Runtime Traffic: A one-stop view for APIs traffic insights on: Target Servers, Virtual Hosts, TLS configuration, traffic changes per environment, and more.

Configuration: Auditing capability for API proxies configuration that provides an end to end visibility over all policies being enforced at the API Proxy level and also the enforcement spectrum of shared flows that are attached at organization or proxy levels.

User Activity: Track sensitive operations being performed by platform users. Analyze suspicious activity by drilling down on suspicious activity.

API10:2019 Insufficient logging & monitoring

Threat Description

Insufficient logging, monitoring, and alerts allows attacks in progress to go undetected and therefore a strategy should be required to obtain insights over critical events that have impact over your business.

Event and logging management strategies for APIs should consider the following best practices:

  • Logs Management Policy: Document and enforce rules to standardize and control logs verbosity, log levels, log integrity, centralized repository, and more
  • Event Management Policy: Guarantee that every event should be traceable to its source. Also, events should be able to be categorized by criticality and business impact
  • Reports and Audits: Security and operations stakeholders should be able to access and react to logs and events in real time. Additionally, reinforcement cycles can be performed by stakeholders to adjust detection patterns based on historical data

Apigee provides the necessary tools to create a comprehensive event and logging management strategy. These tools include:

Message Logging Policy: Create log streams based on traffic data or metadata from your API traffic. You have the flexibility to decide stream verbosity by leveraging conditional logic and message templates.

Google’s Cloud Operation Suite: Leverage the out of box integration into highly scalable monitoring and logging tools from Google.

Service Callout Policy: Adds support for logs streams that require HTTP endpoints to send events.

Analytics: Access and analyze historical traffic metadata through out of box and/or customized reports. Create and manage alerts based on trends and understand traffic anomalies.

API Monitoring: As previously described, this tool provides alerting capabilities that can be triggered based on critical events. Traffic logs can be further analyzed and acted upon.