API Manager - What Policies Should we Use?

In any well-architected MuleSoft implementation, applying the right API policies is essential to ensure security, consistency, and operational control across our API ecosystem. But deciding which policies to apply — and where to apply them — can be challenging without a clear strategy.

API Manager provides a wide range of policies that we can apply to our APIs to enhance security, control access, and enforce best practices. Each policy plays a role in protecting our APIs from specific types of vulnerabilities or misuse. However, this doesn’t mean that every API should have every policy applied. In fact, applying more policies isn’t always better — and doing so without a clear strategy can introduce unnecessary complexity, latency, and even functional issues.

Not all policies make sense in every context. For example, HTTP caching is valuable when dealing with static or infrequently changing data, but it’s not suitable for APIs that handle real-time or non-idempotent operations. Similarly, a CORS policy is only relevant for APIs that are called from browser-based clients — typically public or experience layer APIs.

Performance is another important factor. Each policy we apply introduces an extra processing step, which can increase latency and impact the overall responsiveness of the API. In some cases, policies can also overlap or become redundant. Many organizations, for instance, rely on OAuth 2.0 or JWT for public APIs and reserve simpler mechanisms like client ID enforcement or basic authentication for internal services — making it unnecessary to stack multiple forms of authentication.

So, how do we determine which policies are appropriate for each API? In this post, we’ll walk through a practical set of criteria that help us identify the right policies based on the purpose, exposure, and design of each API. By applying these principles, we can ensure that our policies are targeted, efficient, and aligned with the architecture and purpose of our Application Network.

Exposure Level

One of the first question we need to ask for each API is - How broadly accessible is the API? Is it open to the public, limited to partners, or internal only? The answer will normally be one of these:

• Public APIs - these are most exposed to external threats (e.g., DDoS, abuse, credential stuffing).
• Partner APIs - these are partially trusted but still need strong access control.
• Internal APIs - these are typically accessed from inside the network or via trusted integrations.

In these scenarios, Public APIs require the maximum security perimeter, whereas with Internal APIs we can assume some internal trust but still validate inputs (unless we’re on a Zero-Trust environment)

If an API is publicly accessible, it should always enforce TLS encryption, implement OAuth 2.0 for authentication, and apply rate limiting and spike control to protect against abuse. For partner APIs, client ID enforcement, SLA-based throttling, and IP whitelisting are usually appropriate. Internal APIs, on the other hand, may only need basic authentication and payload validation, as they operate within trusted environments — though it's still important to guard against malformed inputs.

API-led Connectivity

Which tier in our API-led architecture does the API belong to — Experience, Process, or System? This is important, we normally standardize the policies based on the API layer. That’s because:

• Each layer serves a distinct purpose and has different security and operational requirements.
• Applying the wrong policies at the wrong layer can lead to redundancy or inefficiency.

At the Experience layer, policies should focus on controlling traffic and access — such as CORS for cross-domain requests, OAuth 2.0 for identity validation, caching for performance, and rate limiting to manage load. In the Process layer, it's more about orchestration and enrichment — applying header injection (like correlation IDs), SLA tier enforcement, and custom logging for traceability. At the System layer, policies should focus on backend protection, such as schema validation, payload size enforcement, and threat protection (e.g., SQL injection or malicious payload filters).

Data Sensitivity, Compliance & Regulatory Needs

What type of data does the API expose or process — public, confidential, personally identifiable (PII), financial? The more sensitive the data is, the more controls we need to enforce to protect it in transit and at rest. Also, do not forget about regulatory requirements, legal or industry-mandated, such as GDPR, HIPAA, PCI-DSS

For APIs handling sensitive data such as PII or financial information, we should apply strong authentication mechanisms (OAuth 2.0 or mutual TLS), ensure data masking in logs and responses, and include secure headers to prevent leakage. Financial data often requires even stricter controls, such as encrypted payloads and IP restrictions. Public APIs that do not expose sensitive data may only require rate limiting, CORS enforcement, and basic identity controls.

For APIs that fall under GDPR, policies should include PII data masking, consent management (at the Experience layer), audit logging, and secure headers to prevent information leaks. APIs handling credit card data under PCI-DSS must use TLS 1.2 or above, enforce least privilege access, authenticate all users strongly, and log access in detail. Healthcare APIs under HIPAA should protect sensitive health information with encryption, header redaction, access controls, and audit trails.

Traffic Profile and Load Expectations

How much traffic does the API receive? Is it consistent or does it spike under certain conditions? APIs under heavy or spiky load can bring down our APIs and systems if not throttled or managed properly. To avoid that it’s very important to identify traffic patterns. They would help us determine where to apply performance and resilience policies.

If the API is expected to handle high traffic volumes, we should consider applying spike control to prevent sudden surges, and implement caching for idempotent GET requests to reduce backend congestion. APIs that experience unpredictable or bursty traffic should use rate limiting and concurrent request limits. On the other hand, low-volume APIs (such as internal or operational APIs) can often operate with minimal policy overhead, focusing only on basic authentication and essential validations.

Criticality

What is the business impact if the API fails? Is it mission-critical, nice-to-have, or experimental? For critical APIs we need higher assurance in terms of stability, logging, and visibility. On the other hand, for experimental or low-impact APIs we can be more lightweight during early lifecycle stages.

For mission-critical APIs (e.g., payment processing or user authentication), we should use a comprehensive policy stack that includes robust authentication, input validation, traffic controls, error handling, and logging. These APIs should also be fully monitored using Anypoint Monitoring or external observability tools. Less critical APIs might need only client ID enforcement, payload validation, and logging. For non-critical or prototype APIs, we can use lighter governance — just enough to ensure traceability and basic protection.

Consumer Type

Who or what is calling the API? A frontend app? A trusted system? An external client? This is important to understand because different API consumers require different access models.

For example, if the API is consumed by a web or mobile application, we should enforce OAuth 2.0, apply CORS policies, and rate limit requests per client. For server-to-server communication, we should consider using client ID and secret-based access, IP allowlisting, and mutual TLS for added security. Lastly, Internal APIs called by other Mule applications can rely on basic authentication or client ID/secret and may include header injection policies to propagate user context or correlation IDs for observability.

Summary

Here’s a summary table that we can use for each API management case

Criterion	Recommended Policies
Exposure Level	- TLS (HTTPS) - OAuth 2.0 / Client ID Enforcement - Rate Limiting & Spike Control - IP Whitelisting / Geo-blocking - CORS (for public APIs)
API Layer	- Experience: OAuth 2.0, CORS, Caching, Rate Limiting - Process: Header Injection, SLA Tiers, Logging - System: Threat Protection, Schema Validation
Data Sensitivity and Compliance	- OAuth 2.0 or Mutual TLS - Data Masking / Redaction - Secure Headers (e.g., no-cache, X-Content-Type-Options) - Payload Encryption - Logging Control and Sanitization - Audit Logging - Rate Limiting (for abuse prevention)
Traffic Profile	- Rate Limiting - Spike Control - Caching (for GET requests) - Concurrent Rate Limits - Circuit Breakers / Retry Policies
Integration Criticality	- Comprehensive Authentication (OAuth/MTLS) - JSON/XML Threat Protection - SLA Tier Enforcement - Logging & Monitoring - Correlation ID Injection
Consumer Type	- OAuth 2.0 (for apps) - CORS (for browsers) - Client ID + Secret (server-to-server) - IP Whitelisting - Header Injection (internal Mule apps)