Redaguoti

Bendrinti naudojant

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

  • Straipsnis

APPLIES TO: All API Management tiers

Note

This article has been updated to reflect the latest OWASP API Security Top 10 list for 2023.

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 discuss the latest recommendations to mitigate the top 10 API threats identified by OWASP in their 2023 list using Azure API Management.

Even though API Management provides comprehensive controls for API security, other Microsoft services provide complementary functionality to detect or protect against OWASP API threats:

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:2023 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 authentication

The authentication mechanism for a site or API is especially vulnerable because it's open to anonymous users. Assets and endpoints required for authentication, including forgotten password or reset password flows, should be protected to prevent exploitation.

More information about this threat: API2:2023 Broken Authentication

Recommendations

  • Use Microsoft Entra to implement API authentication. Microsoft Entra automatically provides protected, resilient, and geographically distributed login endpoints. Use the validate-azure-ad-token policy to validate Microsoft Entra tokens in incoming API requests.
  • Where authentication is required, API Management supports validation of OAuth 2 tokens, basic authentication, client certificates, and API keys.
    • Ensure proper configuration of authentication methods. For example, set require-expiration-time and require-signed-tokens to true when validating OAuth2 tokens using the validate-jwt policy.
  • Rate limiting can be utilized to reduce the effectiveness of brute force attacks.
  • Client IP filtering can be used to reduce the attack surface area. Network security groups can be applied to virtual networks integrated with API Management.
  • If possible, authenticate to backends from API Management through secure protocols and managed identity or credential manager to authenticate to backends.
  • Ensure tokens or keys are passed in headers and not URLs for inbound requests to API Management and outbound requests to backends.
  • Use Microsoft Entra to secure access to the API Management developer portal.

Broken object property level authorization

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, enabling data injection attacks. Attackers may also discover undocumented interfaces. These vulnerabilities could yield sensitive data to the attacker.

More information about this threat: API3:2023 Broken Object Property Level Authorization

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, and versions to implement breaking changes. You should also version backend interfaces, which typically have a different lifecycle than consumer-facing APIs.
  • Decouple external API interfaces from the internal data implementation. Avoid binding API contracts directly to data contracts in backend services.
  • 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. Content validation in API Management can be used with an XML or JSON schema to block responses with undocumented properties or improper values. For example, remove unneeded JSON properties from a response body. Blocking requests with undocumented properties mitigates attacks, while blocking responses with undocumented properties makes it harder to reverse-engineer potential attack vectors. The validate-content 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.

Unrestricted resource consumption

APIs require resources to run, like memory or CPU, and may include downstream integrations that represent an operating cost (for example, pay-per-request services). Applying limits can help protect APIs from excessive resource consumption.

More information about this threat: API4:2023 Unrestricted Resource Consumption

Recommendations

  • Use rate-limit-by-key or rate-limit policies to apply throttling on shorter time windows. Apply stricter rate-limiting policies on sensitive endpoints, like password reset, sign-in, or sign-up operations, or endpoints that consume significant resources.
  • Use quota-by-key or quota-limit policies to control the allowed number of API calls or bandwidth for longer time frames.
  • Optimize performance with built-in caching, thus reducing the consumption of CPU, memory, and networking resources for certain operations.
  • Apply validation policies.
    • Use the max-size attribute in the validate-content policy to enforce maximum size of requests and responses
    • Define schemas and properties, such as string length or maximum array size, in the API specification. Use validate-content, validate-parameters, and validate-headers policies to enforce those schemas for requests and responses.
    • Use the validate-graphql-request policy for GraphQL APIs and configure max-depth and max-size parameters.
    • Configure alerts in Azure Monitor for excessive consumption of data by users.
  • For generative AI APIs:
  • 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 time frame.
    • Define timeout in the forward-request policy and strive for the shortest acceptable value.
    • Limit the number of parallel backend connections with the limit-concurrency policy.
  • 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.
  • While Azure has both platform-level protection and enhanced protection against distributed denial of service (DDoS) attacks, application (layer 7) protection for APIs can be improved by deploying a bot protection service in front of API Management - for example, Azure Application Gateway, Azure Front Door, or Azure DDoS Protection. When using a web application firewall (WAF) policy with Azure Application Gateway or Azure Front Door, consider using Microsoft_BotManagerRuleSet_1.0.

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:2023 Broken function level authorization

Recommendations

  • By default, protect all API endpoints in API Management with subscription keys or all-APIs-level authorization policy. If applicable, define other authorization policies for specific APIs or API operations.
  • Validate OAuth tokens using policies.
    • Use validate-azure-ad-token policy to validate Microsoft Entra tokens. Specify all required claims and, if applicable, specify authorized applications.
    • For validating tokens not issued by Microsoft Entra, define a validate-jwt policy and enforce required token claims. If possible, require expiration time.
    • If possible, use encrypted tokens or list specific applications for access.
    • Monitor and review requests rejected due to lack of authorization.
  • 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.
  • If client IPs are known, use an ip-filter policy to allow traffic only from authorized IP addresses.
  • Use the validate-client-certificate policy to enforce that a certificate presented by a client to an API Management instance matches specified validation rules and claims.

Unrestricted access to sensitive business flows

APIs can expose a wide range of functionality to the consuming application. It's important for API authors to understand the business flows the API provides and the associated sensitivity. There's a greater risk to the business if APIs exposing sensitive flows don't implement appropriate protections.

More information about this threat: API6:2023 Unrestricted Access to Sensitive Business Flows

Recommendations

  • Reduce or block access based on client fingerprints. For example, use the return-response policy with the choose policy to block traffic from headless browsers based on the User-Agent header or consistency of other headers.
  • Use validate-parameters policy to enforce that request headers match the API specification.
  • Use ip-filter policy to allow requests only from known IP addresses or deny access from specific IPs.
  • Use private networking features to limit external connectivity to internal APIs.
  • Use rate-limit-by-key policy to limit spikes in API consumption based on user identity, IP address, or another value.
  • Front API Management with Azure Application Gateway or Azure DDoS Protection service to detect and block bot traffic.

Server side request forgery

A server side request forgery vulnerability could occur when the API fetches a downstream resource based on the value of a URL which has been passed by the API caller without appropriate validation checks.

More information about this threat: API7:2023 Server Side Request Forgery

Recommendations

  • If possible, don't use URLs provided in the client payloads, for example, as parameters for backend URLs, send-request policy, or rewrite-url policy.
  • If API Management or backend services use URLs provided in request payload for business logic, define and enforce a limited list of hostnames, ports, media types, or other attributes with policies in API Management, such as the choose policy and policy expressions.
  • Define the timeout attribute in the forward-request and send-request policies.
  • Validate and sanitize request and response data with validation policies. If needed, use the set-body policy to process the response and avoid returning raw data.
  • Use private networking to restrict connectivity. For example, if the API doesn't need to be public, restrict connectivity from the internet to reduce the attack surface.

Security misconfiguration

Attackers may attempt to exploit security misconfiguration vulnerabilities such as:

  • Missing security hardening
  • Unnecessarily enabled features
  • Network connections unnecessarily open to the internet
  • Use of weak protocols or ciphers

More information about this threat: API8:2023 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. You can audit and enforce this setting using Azure Policy.
  • 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 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. If you use Microsoft Entra, the validate-azure-ad-token policy provides a more comprehensive and easier way to validate security tokens.
    • Configure the CORS policy and don't use wildcard * for any configuration option. Instead, explicitly list allowed values.
    • Set validation policies 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 Azure 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.
  • Ensure that your APIs require subscription keys, even if all products are configured to require subscription keys. Learn more
  • Require subscription approval for all products and carefully review all subscription requests.
  • 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. Use managed identity to authenticate to key vaults.
  • 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.
  • Where possible, use credential manager or managed identity to authenticate against backend services.
  • 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 Azure Policy to enforce API Management resource-level configuration and role-based access control (RBAC) permissions to control resource access. Grant minimum required privileges to every user.
  • 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.

Improper inventory 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:2023 Improper inventory 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 manage API changes. 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. Ensure security controls are implemented across all available API versions.
  • Separate environments (such as development, test, and production) with different API Management services. Ensure that each API Management service connects to its dependencies in the same environment. For example, in the test environment, the test API Management resource should connect to a test Azure Key Vault resource and the test versions of backend services. Use DevOps automation and infrastructure-as-code practices to help maintain consistency and accuracy between environments and reduce human errors.
  • Isolate administrative permissions to APIs and related resources using workspaces.
  • Use tags to organize APIs and products and group them for publishing.
  • Publish APIs for consumption through a 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.
  • Use Azure API Center to maintain a comprehensive, centralized inventory of APIs, versions, and deployments, even if APIs aren't managed in Azure API Management.

Unsafe consumption of APIs

Resources obtained through downstream integrations tend to be more highly trusted than API input from the caller or end user. If the appropriate sanitization and security standards are not applied, the API could be vulnerable, even if the integration is provided through a trusted service.

More information about this threat: API10:2023 Unsafe Consumption of APIs

Recommendations

  • Consider using API Management to act as a façade for downstream dependencies that the backend APIs integrate with.
  • If downstream dependencies are fronted with API Management or if downstream dependencies are consumed with a send-request policy in API Management, use the recommendations from other sections of this documentation to ensure their safe and controlled consumption, including:
    • Ensure secure transport is enabled and enforce TLS/SSL configuration
    • If possible, authenticate with credential manager or managed identity
    • Control consumption with rate-limit-by-key and quota-limit-by-key policies
    • Log or block responses that are incompliant with the API specification using the validate-content and validate-header policies
    • Transform responses with the set-body policy, for example to remove unnecessary or sensitive information
    • Configure timeouts and limit concurrency

Related content

Learn more about: