Prompt and context
Gateway API v1.5 moved the HTTPRoute CORS filter to the Standard channel. It lets a route rule declare allowed origins, methods, request headers, exposed headers, and preflight cache time. The question tests whether you can place cross-origin policy at the right gateway boundary while preserving server authorization and implementation-specific verification.
What interviewers assess
Interviewers look for a distinction between browser CORS protection, gateway response headers, and real identity authorization. A strong answer covers the OPTIONS preflight path, credentials and origins, wildcard risk, least privilege per route, and whether the Gateway implementation supports the filter. Writing only allowOrigins: "*" does not demonstrate a secure design.
Questions to clarify before answering
Which origins and resources need cross-origin access?
List production, preview, administration, and local-development origins, authorizing them per route rather than across an entire domain. The list should be auditable and expirable, with test origins kept out of production.
Are credentials included?
Confirm whether requests carry cookies, HTTP authentication, or another credential. Credentialed requests need a stricter origin and response-header policy; arbitrary origins should not be combined with credentials by default.
Who owns authorization and policy release?
Define Gateway, application, and identity-service responsibilities. CORS controls whether browser scripts can read a response; it does not replace token validation, tenant isolation, or resource authorization.
30-second answer framework
“I first scope origins by HTTPRoute and business resource instead of widening the whole Gateway. For each route I specify origins, methods, headers, exposed headers, and maxAge; credentialed routes use reviewed origins and verified response headers. I test OPTIONS preflight, the actual request, errors, and cache expiry, and confirm the Gateway implementation supports the filter. Finally, I verify CORS as a browser access boundary separately from server authorization, audit, and rollback.”
Step-by-step deep answer
Step 1: Build least privilege per route
Record the resource, origins, allowed methods, and header needs for each HTTPRoute. Public read-only resources and credentialed account resources should use separate rules so one permissive policy cannot cover the whole domain.
Step 2: Configure filter fields
Set allowOrigins, allowMethods, allowHeaders, exposeHeaders, and maxAge from the actual need. Review origin patterns against implementation documentation and security policy; prefer explicit origins over unnecessary wildcards.
Step 3: Handle preflight correctly
The browser sends OPTIONS with Origin, Access-Control-Request-Method, and possibly Access-Control-Request-Headers. The Gateway must return policy-consistent CORS headers and clearly reject disallowed requests instead of forwarding preflight to a backend that does not understand CORS.
Step 4: Separate credentials and authorization
Design credential behavior with cookie attributes, CSRF protection, token validation, and server authorization. Even if a browser blocks script access, the server must authorize the request itself.
Step 5: Verify implementation and rollback
Confirm that the Gateway controller supports the v1.5 Standard CORS filter and its field semantics. Reproduce preflight, actual requests, failures, redirects, and cache behavior with a browser and curl; record policy changes, metrics, and rollback steps.
High-quality sample answer
I would scope origins per HTTPRoute, keeping a public search interface separate from a credentialed account interface. Each rule would specify allowed origins, methods, request headers, exposed headers, and preflight cache time; credentialed access would use only reviewed production origins. Before release I would test OPTIONS and actual requests in a browser, including errors, redirects, and cache expiry, then use curl and Gateway controller status conditions to confirm the configuration is active. CORS only defines the browser-read boundary; the server still enforces identity, tenant, and resource authorization. Any controller semantic difference would be tracked in a compatibility matrix with an application-layer fallback.
Common mistakes
- Mistake: Allowing every origin globally. → Why it fails: Any route may become readable by browser scripts, making audit and revocation difficult. → Fix: Build the smallest origin set per HTTPRoute.
- Mistake: Configuring only actual requests and ignoring OPTIONS. → Why it fails: Complex methods or headers are blocked by preflight first. → Fix: Test preflight and actual responses separately.
- Mistake: Treating CORS as authorization. → Why it fails: Non-browser clients can still call the service directly. → Fix: Keep server identity, tenant, and resource checks.
- Mistake: Shipping v1.5 fields without testing the controller. → Why it fails: Implementations may ignore, reject, or interpret them differently. → Fix: Check support matrices, status conditions, and real traffic replays.
Follow-ups and responses
Follow-up 1: Why not set CORS only in the application?
The application can own resource-specific policy, while the Gateway can handle route-level preflight and the cross-service boundary. When both layers set headers, define precedence to avoid duplicates or conflicts.
Follow-up 2: Should maxAge always be as long as possible?
No. A longer preflight cache reduces OPTIONS traffic but delays revocation. Choose it from change frequency, risk, and browser behavior, and keep a versioned-origin or short-TTL path for urgent withdrawal.
Follow-up 3: When is a wildcard origin acceptable?
Only for genuinely public resources with no credentials and an approved risk assessment. Account, administration, and tenant data should use explicit origins and tested wildcard behavior.
Follow-up 4: How would you detect an origin being allowed by mistake?
Log Origin, route, preflight result, and policy version; audit origin changes. Run an automated matrix from allowed, disallowed, and expired origins, blocking release when response headers diverge from policy.