How to handle HTTP OPTIONS requests in Spring Boot?
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
HTTP OPTIONS requests are used to discover allowed methods and are central to browser CORS preflight behavior. In Spring Boot, mishandled OPTIONS requests often appear as frontend CORS failures even when main endpoints work. Correct handling requires alignment between MVC routing, security rules, and CORS configuration.
Why OPTIONS Requests Matter
Browsers send a preflight OPTIONS request before certain cross-origin calls. If this preflight fails, the actual request is never sent. That means backend logs may show only OPTIONS failures while business endpoints seem fine.
A minimal controller-level mapping can handle OPTIONS directly:
This is explicit, but global CORS config is often cleaner for larger apps.
Global CORS Configuration
A centralized CORS configuration avoids duplicated annotations and makes policy easier to audit.
With this in place, preflight requests are answered consistently.
Spring Security Interaction
If Spring Security blocks OPTIONS requests, CORS config alone is not enough. Permit OPTIONS paths explicitly.
This step resolves many real-world preflight failures.
Testing OPTIONS Endpoints
Add integration tests for preflight behavior, not only business methods.
This prevents CORS regressions during security refactors.
Controller Annotation Alternative
For smaller services, @CrossOrigin at controller or method level may be enough. This is less centralized but useful for scoped policies.
When policy grows, migrate this local annotation style to global config for consistency.
Proxy and Gateway Considerations
OPTIONS requests may be intercepted by API gateways or reverse proxies before reaching Spring Boot. Confirm that infrastructure layers forward preflight headers unchanged.
Inspect response headers for allowed methods and origins. This direct check narrows whether issue is in app code or infrastructure.
Practical Debug Workflow
A practical sequence is:
- Verify direct OPTIONS response from service.
- Verify security permit rules.
- Verify browser request headers in dev tools.
- Verify gateway behavior in staging.
Following this sequence avoids random config changes and shortens troubleshooting time.
Common Pitfalls
- Configuring CORS on controllers but not permitting OPTIONS in security rules.
- Allowing methods list that excludes OPTIONS.
- Testing API with Postman only and missing browser preflight behavior.
- Using wildcard origins with credentials and violating browser rules.
- Applying conflicting CORS settings in multiple config locations.
Summary
- OPTIONS handling is critical for browser CORS preflight success.
- Use centralized CORS policy where possible.
- Ensure Spring Security permits OPTIONS requests.
- Add tests for preflight paths, not only main endpoints.
- Keep CORS and security configuration aligned.
Related reading
- How to handle Jetty exception - a long running HTTP request times out, but the process it calls never terminates and Jetty is unhappy
- How to handle reordered RPC in raft
- How to handle timeout in Async Socket?
- How to identify if the OAuth token has expired?
- How to hash a string into 8 digits?
- How to ignore SSL certificate errors in Apache HttpClient 4.0
- How to handle InterruptException on Futureget?
- How to handle java.util.concurrent.TimeoutException android.os.BinderProxy.finalize timed out after 10 seconds errors?

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.