CORS (Cross-Origin Resource Sharing)
CORS on webMethods API Gateway: How to configure, test, and troubleshoot CORS is one of those things that’s invisible when it’s right and maddening when it’s wrong. If you’re exposing APIs through IBM’s webMethods API Gateway and serving a browser-based frontend, this guide will show you how to set up CORS correctly, verify it with curl, and fix common issues fast. TL;DR Enable the CORS policy on your API (or as a Global Policy) in API Gateway. Explicitly allow the frontend Origin, HTTP methods, and custom headers your app uses. Let the gateway handle preflight (OPTIONS) requests and don’t require authentication for them. Test with curl using -H “Origin: …” and use -X OPTIONS for preflight checks. Watch out for credentials + “*” mismatch, missing allowed headers, or upstream proxies blocking OPTIONS. What CORS is (and isn’t) What it is: A browser-enforced security model that restricts cross-origin HTTP calls made by frontend code (e.g., https://app.example.com calling https://api.example.com). What it isn’t: A server-to-server restriction. curl, Postman, and backend services aren’t blocked by CORS. Simple vs preflight: Simple requests: GET/HEAD/POST with limited headers may not trigger a preflight. Preflight: For other methods (PUT/PATCH/DELETE), custom headers (Authorization, X-API-Key, etc.), or content types, the browser sends an OPTIONS request first to check what’s allowed. Key headers ...