Recommendations to mitigate OWASP API Security Top 10 threats using API Management

  • Article

APPLIES TO: All API Management tiers

The Open Web Application Security Project (OWASP) Foundation works to improve software security through its community-led open source software projects, hundreds of chapters worldwide, tens of thousands of members, and by hosting local and global conferences.

The OWASP API Security Project focuses on strategies and solutions to understand and mitigate the unique vulnerabilities and security risks of APIs. In this article, we'll discuss recommendations to use Azure API Management to mitigate the top 10 API threats identified by OWASP.

Broken object level authorization

API objects that aren't protected with the appropriate level of authorization may be vulnerable to data leaks and unauthorized data manipulation through weak object access identifiers. For example, an attacker could exploit an integer object identifier, which can be iterated.

More information about this threat: API1:2019 Broken Object Level Authorization

Recommendations

  • The best place to implement object level authorization is within the backend API itself. At the backend, the correct authorization decisions can be made at the request (or object) level, where applicable, using logic applicable to the domain and API. Consider scenarios where a given request may yield differing levels of detail in the response, depending on the requestor's permissions and authorization.

  • If a current vulnerable API can't be changed at the backend, then API Management could be used as a fallback. For example:

    • Use a custom policy to implement object-level authorization, if it's not implemented in the backend.

    • Implement a custom policy to map identifiers from request to backend and from backend to client, so that internal identifiers aren't exposed.

      In these cases, the custom policy could be a policy expression with a look-up (for example, a dictionary) or integration with another service through the send request policy.

  • For GraphQL scenarios, enforce object-level authorization through the validate GraphQL request policy, using the authorize element.

Broken user authentication

Authentication mechanisms are often implemented incorrectly or missing, allowing attackers to exploit implementation flaws to access data.

More information about this threat: API2:2019 Broken User Authentication

Recommendations

Use API Management for user authentication and authorization:

  • Authentication - API Management supports the following authentication methods:

    • Basic authentication policy - Username and password credentials.

    • Subscription key - A subscription key provides a similar level of security as basic authentication and may not be sufficient alone. If the subscription key is compromised, an attacker may get unlimited access to the system.

    • Client certificate policy - Using client certificates is more secure than basic credentials or subscription key, but it doesn't allow the flexibility provided by token-based authorization protocols such as OAuth 2.0.

  • Authorization - API Management supports a validate JWT policy to check the validity of an incoming OAuth 2.0 JWT access token based on information obtained from the OAuth identity provider's metadata endpoint. Configure the policy to check relevant token claims, audience, and expiration time. Learn more about protecting an API using OAuth 2.0 authorization and Microsoft Entra ID.

More recommendations:

  • Use policies in API Management to increase security. For example, call rate limiting slows down bad actors using brute force attacks to compromise credentials.

  • APIs should use TLS/SSL (transport security) to protect the credentials or tokens. Credentials and tokens should be sent in request headers and not as query parameters.

  • In the API Management developer portal, configure Microsoft Entra ID or Azure Active Directory B2C as the identity provider to increase the account security. The developer portal uses CAPTCHA to mitigate brute force attacks.

Excessive data exposure

Good API interface design is deceptively challenging. Often, particularly with legacy APIs that have evolved over time, the request and response interfaces contain more data fields than the consuming applications require.

A bad actor could attempt to access the API directly (perhaps by replaying a valid request), or sniff the traffic between server and API. Analysis of the API actions and the data available could yield sensitive data to the attacker, which isn't surfaced to, or used by, the frontend application.

More information about this threat: API3:2019 Excessive Data Exposure

Recommendations

  • The best approach to mitigating this vulnerability is to ensure that the external interfaces defined at the backend API are designed carefully and, ideally, independently of the data persistence. They should contain only the fields required by consumers of the API. APIs should be reviewed frequently, and legacy fields deprecated, then removed.

    In API Management, use:

    • Revisions to gracefully control nonbreaking changes, for example, the addition of a field to an interface. You may use revisions along with a versioning implementation at the backend.

    • Versions for breaking changes, for example, the removal of a field from an interface.

  • If it's not possible to alter the backend interface design and excessive data is a concern, use API Management transformation policies to rewrite response payloads and mask or filter data. For example, remove unneeded JSON properties from a response body.

  • Response content validation in API Management can be used with an XML or JSON schema to block responses with undocumented properties or improper values. The policy also supports blocking responses exceeding a specified size.

  • Use the validate status code policy to block responses with errors undefined in the API schema.

  • Use the validate headers policy to block responses with headers that aren't defined in the schema or don't comply to their definition in the schema. Remove unwanted headers with the set header policy.

  • For GraphQL scenarios, use the validate GraphQL request policy to validate GraphQL requests, authorize access to specific query paths, and limit response size.

Lack of resources and rate limiting

Lack of rate limiting may lead to data exfiltration or successful DDoS attacks on backend services, causing an outage for all consumers.

More information about this threat: API4:2019 Lack of resources and rate limiting

Recommendations

  • Use rate limit (short-term) and quota limit (long-term) policies to control the allowed number of API calls or bandwidth per consumer.

  • Define strict request object definitions and their properties in the OpenAPI definition. For example, define the max value for paging integers, maxLength and regular expression (regex) for strings. Enforce those schemas with the validate content and validate parameters policies in API Management.

  • Enforce maximum size of the request with the validate content policy.

  • Optimize performance with built-in caching, thus reducing the consumption of CPU, memory, and networking resources for certain operations.

  • Enforce authentication for API calls (see Broken user authentication). Revoke access for abusive users. For example, deactivate the subscription key, block the IP address with the restrict caller IPs policy, or reject requests for a certain user claim from a JWT token.

  • Apply a CORS policy to control the websites that are allowed to load the resources served through the API. To avoid overly permissive configurations, don’t use wildcard values (*) in the CORS policy.

  • Minimize the time it takes a backend service to respond. The longer the backend service takes to respond, the longer the connection is occupied in API Management, therefore reducing the number of requests that can be served in a given timeframe.

  • While API Management can protect backend services from DDoS attacks, it may be vulnerable to those attacks itself. Deploy a bot protection service in front of API Management (for example, Azure Application Gateway) to better protect against DDoS attacks.

Broken function level authorization

Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources or administrative functions.

More information about this threat: API5:2019 Broken function level authorization

Recommendations

  • By default, protect all API endpoints in API Management with subscription keys.

  • Define a validate JWT policy and enforce required token claims. If certain operations require stricter claims enforcement, define extra validate-jwt policies for those operations only.

  • Use an Azure virtual network or Private Link to hide API endpoints from the internet. Learn more about virtual network options with API Management.

  • Don't define wildcard API operations (that is, "catch-all" APIs with * as the path). Ensure that API Management only serves requests for explicitly defined endpoints, and requests to undefined endpoints are rejected.

  • Don't publish APIs with open products that don't require a subscription.

Mass assignment

If an API offers more fields than the client requires for a given action, an attacker may inject excessive properties to perform unauthorized operations on data. Attackers may discover undocumented properties by inspecting the format of requests and responses or other APIs, or guessing them. This vulnerability is especially applicable if you don’t use strongly typed programming languages.

More information about this threat: API6:2019 Mass assignment

Recommendations

  • External API interfaces should be decoupled from the internal data implementation. Avoid binding API contracts directly to data contracts in backend services. Review the API design frequently, and deprecate and remove legacy properties using versioning in API Management.

  • Precisely define XML and JSON contracts in the API schema and use validate content and validate parameters policies to block requests and responses with undocumented properties. Blocking requests with undocumented properties mitigates attacks, while blocking responses with undocumented properties makes it harder to reverse-engineer potential attack vectors.

  • If the backend interface can't be changed, use transformation policies to rewrite request and response payloads and decouple the API contracts from backend contracts. For example, mask or filter data or remove unneeded JSON properties.

Security misconfiguration

Attackers may attempt to exploit security misconfiguration vulnerabilities such as:

  • Missing security hardening
  • Unnecessary enabled features
  • Network connections unnecessarily open to the internet
  • Use of weak protocols or ciphers
  • Other settings or endpoints that may allow unauthorized access to the system

More information about this threat: API7:2019 Security misconfiguration

Recommendations

  • Correctly configure gateway TLS. Don't use vulnerable protocols (for example, TLS 1.0, 1.1) or ciphers.

  • Configure APIs to accept encrypted traffic only, for example through HTTPS or WSS protocols.

  • Consider deploying API Management behind a private endpoint or attached to a virtual network deployed in internal mode. In internal networks, access can be controlled from within the private network (via firewall or network security groups) and from the internet (via a reverse proxy).

  • Use Azure API Management policies:

    • Always inherit parent policies through the <base> tag.

    • When using OAuth 2.0, configure and test the validate JWT policy to check the existence and validity of the JWT token before it reaches the backend. Automatically check the token expiration time, token signature, and issuer. Enforce claims, audiences, token expiration, and token signature through policy settings.

    • Configure the CORS policy and don't use wildcard * for any configuration option. Instead, explicitly list allowed values.

    • Set validation policies to prevent in production environments to validate JSON and XML schemas, headers, query parameters, and status codes, and to enforce the maximum size for request or response.

    • If API Management is outside a network boundary, client IP validation is still possible using the restrict caller IPs policy. Ensure that it uses an allowlist, not a blocklist.

    • If client certificates are used between caller and API Management, use the validate client certificate policy. Ensure that the validate-revocation, validate-trust, validate-not-before, and validate-not-after attributes are all set to true.

      • Client certificates (mutual TLS) can also be applied between API Management and the backend. The backend should:

        • Have authorization credentials configured

        • Validate the certificate chain where applicable

        • Validate the certificate name where applicable

  • For GraphQL scenarios, use the validate GraphQL request policy. Ensure that the authorization element and max-size and max-depth attributes are set.

  • Don't store secrets in policy files or in source control. Always use API Management named values or fetch the secrets at runtime using custom policy expressions.

    • Named values should be integrated with Key Vault or encrypted within API Management by marking them "secret". Never store secrets in plain-text named values.

  • Publish APIs through products, which require subscriptions. Don't use open products that don't require a subscription.

  • Use Key Vault integration to manage all certificates – this centralizes certificate management and can help to ease operations management tasks such as certificate renewal or revocation.

  • When using the self-hosted-gateway, ensure that there's a process in place to update the image to the latest version periodically.

  • Represent backend services as backend entities. Configure authorization credentials, certificate chain validation, and certificate name validation where applicable.

  • When using the developer portal:

    • If you choose to self-host the developer portal, ensure there's a process in place to periodically update the self-hosted portal to the latest version. Updates for the default managed version are automatic.

    • Use Microsoft Entra ID or Azure Active Directory B2C for user sign-up and sign-in. Disable the default username and password authentication, which is less secure.

    • Assign user groups to products, to control the visibility of APIs in the portal.

  • Use a DevOps process and infrastructure-as-code approach outside of a development environment to ensure consistency of API Management content and configuration changes and to minimize human errors.

  • Don't use any deprecated features.

Injection

Any endpoint accepting user data is potentially vulnerable to an injection exploit. Examples include, but aren't limited to:

  • Command injection, where a bad actor attempts to alter the API request to execute commands on the operating system hosting the API

  • SQL injection, where a bad actor attempts to alter the API request to execute commands and queries against the database an API depends on

More information about this threat: API8:2019 Injection

Recommendations

  • Modern Web Application Firewall (WAF) policies cover many common injection vulnerabilities. While API Management doesn’t have a built-in WAF component, deploying a WAF upstream (in front) of the API Management instance is strongly recommended. For example, use Azure Application Gateway.

    Important

    Ensure that a bad actor can't bypass the gateway hosting the WAF and connect directly to the API Management gateway or backend API itself. Possible mitigations include: network ACLs, using API Management policy to restrict inbound traffic by client IP, removing public access where not required, and client certificate authentication (also known as mutual TLS or mTLS).

  • Use schema and parameter validation policies, where applicable, to further constrain and validate the request before it reaches the backend API service.

    The schema supplied with the API definition should have a regex pattern constraint applied to vulnerable fields. Each regex should be tested to ensure that it constrains the field sufficiently to mitigate common injection attempts.

Improper assets management

Vulnerabilities related to improper assets management include:

  • Lack of proper API documentation or ownership information

  • Excessive numbers of older API versions, which may be missing security fixes

More information about this threat: API9:2019 Improper assets management

Recommendations

  • Use a well-defined OpenAPI specification as the source for importing REST APIs. The specification allows encapsulation of the API definition, including self-documenting metadata.

    • Use API interfaces with precise paths, data schemas, headers, query parameters, and status codes. Avoid wildcard operations. Provide descriptions for each API and operation and include contact and license information.

    • Avoid endpoints that don’t directly contribute to the business objective. They unnecessarily increase the attack surface area and make it harder to evolve the API.

  • Use revisions and versions in API Management to govern and control the API endpoints. Have a strong backend versioning strategy and commit to a maximum number of supported API versions (for example, 2 or 3 prior versions). Plan to quickly deprecate and ultimately remove older, often less secure, API versions.

  • Use an API Management instance per environment (such as development, test, and production). Ensure that each API Management instance connects to its dependencies in the same environment.

  • Use tags to organize APIs and products and group them for publishing.

  • Publish APIs for consumption through the built-in developer portal. Make sure the API documentation is up-to-date.

  • Discover undocumented or unmanaged APIs and expose them through API Management for better control.

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, pivot to more systems to tamper with, and extract or destroy data. Most breach studies demonstrate that the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

More information about this threat: API10:2019 Insufficient logging and monitoring

Recommendations

Next steps

Learn more about: