Security teams should treat CORS as an allowlist control, not a blanket permission model. Define trusted origins explicitly, limit methods and headers to what the application actually needs, and avoid wildcard origins for authenticated or sensitive workloads. Centralising policy in an API gateway helps keep enforcement consistent across services and reduces the chance of configuration drift.
How CORS should be configured in an API gateway
CORS should be configured as an explicit allowlist at the gateway, with the gateway deciding which browser origins may send cross-origin requests and under which conditions. That means enumerating trusted origins, limiting methods and headers to the minimum required, and avoiding permissive wildcard settings on authenticated or sensitive APIs. The gateway becomes the consistent enforcement point, while backend services remain shielded from browser-origin variation.
The practical value of gateway-based CORS is control consistency. When policy is spread across services, teams tend to drift into mismatched origin rules, overbroad headers, or temporary exceptions that become permanent. Centralising the decision in one layer reduces those configuration errors, but only if the gateway policy is maintained as rigorously as any other access control.
For APIs that support browser clients, the most important design choice is whether a request is genuinely meant to be used cross-origin at all. If it is not, do not enable CORS broadly and rely on client-side convenience. If it is, scope the policy to the exact origins, verbs, and request headers needed for the business flow, and treat credentialed requests with extra caution because they raise the consequence of an overly permissive origin decision.
Where unsafe cross-origin access usually comes from
Unsafe CORS configurations are usually created by convenience, not intent. Common failure modes include reflecting the caller’s Origin header without strong validation, permitting broad API-origin access patterns, allowing wildcard origins alongside credentials, and granting methods or headers that the application never uses. Each of these expands the browser’s ability to reach the API beyond what the business actually needs.
Gateway architectures add their own failure modes. Teams may assume the gateway will “take care of CORS” while backend routes still emit conflicting headers, or they may apply a single permissive rule set across unrelated APIs because it is simpler to operate. That creates a hidden policy mismatch: one sensitive route inherits the same browser exposure as a low-risk public route, even though the trust boundary is different.
Cross-origin policy is also easy to get wrong during change. A temporary exception added for a partner integration, local development, or a migration can outlive its purpose. In a gateway, that exception matters more because it is often shared by many routes, so a single loose rule can multiply exposure across multiple services.
Practitioner guidance for gateway policy, testing, and review
What to verify: Verify that the gateway only returns CORS headers for approved origins and only on routes that need browser access. Test both preflight and actual requests, because a configuration that looks safe on simple GET traffic may still expose sensitive operations through allowed methods or headers.
Common mistake: Do not use wildcard origins for authenticated traffic, and do not confuse “the browser blocks the response” with “the request is safe.” A browser-visible response restriction is not the same as a server-side access decision, so the gateway policy still needs to be explicit, minimal, and route-aware. For verification discipline, use the OWASP Web Security Testing Guide to exercise preflight handling, header reflection, and origin enforcement.
What good looks like: The gateway has a small, reviewable set of origin rules, each tied to a documented application use case. Sensitive APIs either have no CORS support at all or only allow the exact trusted origins required by the client architecture. For broader control alignment, map the gateway policy to CIS Controls v8 and the access-control principles in NIST SP 800-207 Zero Trust Architecture so origin trust is treated as a deliberate policy decision.
Practitioner takeaway: Configure CORS as a narrowly scoped browser-access policy, not as a convenience setting, and assume that any overbroad origin rule in a gateway can become a reusable exposure across the whole API estate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Gateway CORS is an access decision that must be narrowly scoped. |
| Recommendation — Restrict allowed origins, methods, and headers to the minimum required for each API. | ||
| NIST CSF 2.0 | PR.AC-3 — Remote Access | CORS governs which remote browser origins can interact with an API. |
| PR.AC-4 — Access Permissions and Authorizations | Safe CORS depends on explicit authorization for allowed origins and requests. | |
| Recommendation — Limit cross-origin access to explicitly approved browser clients and routes. Enforce allowlisted origin decisions at the gateway and deny all others by default. | ||
| NIST Zero Trust (SP 800-207) | SC-3 — Access Control in Application and Service Traffic | Gateway policy should separate trusted cross-origin traffic from all other traffic. |
| Recommendation — Apply policy enforcement at the gateway so browser-origin trust is explicit and centralized. | ||
Related resources from NHI Mgmt Group
- How should security teams configure CORS to allow legitimate cross-origin requests without opening broad browser access?
- How should security teams manage cross namespace access for plugins and secrets in Kubernetes API gateway environments?
- How should security teams configure CORS in a Rails API without opening it too widely?
- How should security teams govern partner API access at the gateway?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
