[Server] Extract CORS handling into CorsMiddleware

[chr-hertel]

Summary

• Extracts inline CORS handling from StreamableHttpTransport into a dedicated CorsMiddleware (PSR-15)
• CorsMiddleware is automatically prepended to the middleware chain, handling OPTIONS preflight and applying CORS headers to all responses
• Changes default Access-Control-Allow-Origin from * (allow all) to not set (block cross-origin), with explicit opt-in via allowedOrigins
  • addressing a security design flaw reported by @srikanthramu
  • Fix Hardcoded Wildcard CORS (Access-Control-Allow-Origin: *) #280

Breaking Changes

• The $corsHeaders constructor parameter on StreamableHttpTransport is replaced by ?CorsMiddleware $corsMiddleware
• Default CORS behavior no longer sets Access-Control-Allow-Origin: * — use new CorsMiddleware(allowedOrigins: ['*']) to restore

[CodeWithKyrian]

This is a solid refactor...makes a lot of sense.

One thing I was wondering though: instead of introducing a dedicated $corsMiddleware parameter on the transport, would it be feasible to just work with the existing $middleware array?

For example:

• accept CorsMiddleware as part of the middleware list
• detect if it’s already present
• ensure it’s in the correct position (e.g. prepend or reorder if needed)
• optionally inject a default if none is provided

That way everything stays within a single middleware pipeline instead of splitting configuration paths.

I get that this might complicate the setup a bit, so maybe that’s why you went this route...but I was just curious if you explored that approach at all?

[chr-hertel]

@CodeWithKyrian Thanks, yeah, true - so similar to the approach in #260, right?

[CodeWithKyrian]

Yes exactly!

[soyuka]

let's say I use the mcp bundle with the famous https://github.com/nelmio/NelmioCorsBundle how am I going to avoid conflicts?

[chr-hertel]

Haven't tested, but we'd need a way to opt-out completely you mean?