Configure Cross-Domain and Advanced Transformation Policies
Cross-Origin Resource Sharing (CORS) policies let web applications running on one domain call APIs hosted on a different domain. In Azure API Management, you configure the CORS policy to list which origins, HTTP methods, and headers are permitted. When a browser sends a preflight request, the policy checks whether the actual request is safe to allow. This is essential for modern web apps that consume APIs from separate domains.
Advanced transformation policies change the content of requests and responses without touching the backend code. The XSL Transform policy uses XSLT to convert XML data between formats, while liquid templates handle JSON transformations. These policies live in the inbound, outbound, or backend sections of the policy XML and can reshape data, add or remove elements, and apply custom logic.
Response caching stores API responses at different scopes—global, API, or operation—to reduce backend load and speed up repeated requests. You control what gets cached based on query parameters, headers, or other criteria so clients get fresh data when needed. The policy editor in the Azure portal provides both a form-based interface and direct XML editing for configuring these options.
Designing and Applying Security Policies
API policies in Azure API Management enforce security, performance, and compliance by controlling how requests are processed and authenticated. The main security objectives are authentication to verify who is calling, authorization to decide what they can access, and IP restrictions to limit where calls originate.
Azure API Management can be placed inside a virtual network to achieve network isolation and protect backend services. Using private endpoints keeps backend services from being exposed to the public internet. You can also connect securely to on-premises networks through VPN and configure the developer portal for internal access only.
Authentication policies go in the inbound section of your API policy. Common options include validate-jwt for checking JSON Web Tokens, basic authentication or bearer tokens for REST API calls, and api-key header checks for simpler key-based access. Beyond identity checks, you can layer on Azure Web Application Firewall to block OWASP top 10 attacks and CORS domain allow lists to restrict browser cross-origin calls.
Azure API Management policies are XML statements that run in order to change how an API behaves. These policies are organized into four sections: inbound for incoming requests, backend for logic before the service call, outbound for the response, and on-error for handling problems. The gateway applies these rules as requests and responses pass between the client and the backend service.
Transformation policies modify message content, such as converting XML to JSON or changing headers. The set-header policy adds, modifies, or removes HTTP headers from requests and responses. The find-and-replace and set-body policies update body content to match what the backend or client expects.
Traffic management policies protect backend services from being overwhelmed. Rate limiting restricts how many calls arrive in a short time, while quotas enforce limits over longer periods like a month. Response caching with cache-lookup and cache-store improves performance by reducing how often the backend must process the same request. Policy expressions using C# syntax provide dynamic control, letting you access the context variable to make decisions based on user IDs or geographic regions.
Implement Advanced Policy Expressions and Composition
Policy expressions use C#-like syntax to control API behavior at runtime. Simple expressions go in @(expression) while multi-statement blocks use @{expression}. These expressions access the implicit context variable containing request and response data, enabling conditional logic and variable assignments without modifying backend services. You can also use .NET Framework types within expressions for more robust configurations.
Policy composition lets you reuse logic across different APIs through includes and fragments. Policy fragments are reusable XML elements containing one or more policies, and you insert them using the include-fragment policy. This approach ensures consistent behavior across APIs while reducing duplication. The base element controls evaluation order by inheriting policies from parent scopes, and placing it at the beginning of each section ensures broader policies run first.
Policies work at five scopes: global, workspace, product, API, and operation. The on-error section captures exceptions during policy execution, and you can access context.LastError to customize error responses. Tools like Azure Copilot and the Visual Studio Code extension help generate and explain policy snippets using natural language prompts.
Policies are XML-based configurations that run in a specific order during the request-response lifecycle. The four processing sections control when transformations or rules apply: inbound handles incoming requests, backend runs before the service call, outbound processes the response, and on-error handles any problems that occur.
Scopes determine how broadly a policy applies across your API Management instance. Global scope affects every API, product scope impacts APIs grouped for specific developers, API scope targets a particular API, and operation scope controls a single action like a specific GET request. Choosing the right scope is essential because it determines which APIs or users are affected by your rules.
When policies exist at multiple levels, they combine through inheritance. The base element tells Azure to include policies from the parent scope, and its placement determines execution order. Placing base before your custom code means broader rules run first, while placing it after lets your custom rules take priority. Always include base to ensure shared security and rate-limiting rules are not accidentally skipped.