CORS: Cross-Origin Resource Sharing in EUDI Wallet Web Services

Cross-Origin Resource Sharing (CORS) is a security mechanism implemented by web browsers that controls how web pages from one origin (domain, protocol, and port combination) can request resources from a different origin. CORS extends the browser's same-origin policy by using HTTP headers to declare which cross-origin requests a server permits. For EUDI Wallet web-based flows -- including online credential verification, wallet registration, and relying party integration -- CORS configuration determines which websites can interact with wallet APIs and credential verification endpoints.

When a web page makes a cross-origin request (for example, a relying party website at bank.example.com calling an API at wallet-api.eudi.eu), the browser follows a specific CORS protocol:

For simple requests (GET or POST with basic headers), the browser sends the request directly but includes an Origin header. The server responds with Access-Control-Allow-Origin indicating whether that origin is permitted. The browser only exposes the response to the page if the origin is allowed.

For complex requests (PUT, DELETE, or requests with custom headers like Authorization), the browser first sends a preflight OPTIONS request asking the server what is permitted. The server responds with headers like Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers. Only if the preflight response permits the intended request does the browser send the actual request.

The Access-Control-Max-Age header tells the browser how long to cache the preflight response, reducing latency for subsequent requests. The Access-Control-Allow-Credentials header controls whether cookies and authorization headers can be included in cross-origin requests -- critical for authenticated EUDI Wallet API calls.

EUDI Wallet backend services interact with web-based relying parties through several endpoints that require CORS configuration:

• •Authorization endpoints: Where relying parties initiate credential presentation requests. CORS must allow the relying party's specific domain to make POST requests with JSON content types.
• •Credential verification endpoints: Where verifiers submit presentation tokens for validation. These require authenticated cross-origin access with appropriate credential headers.
• •Status/revocation endpoints: Where verifiers check credential validity. These may use more permissive CORS settings since they serve public revocation data, but should still not use wildcard origins in production.
• •Metadata endpoints: Serving OpenID configuration, credential schemas, and trust framework data. These are typically read-only and may allow broader CORS access.

For EUDI Wallet deployments, CORS security requires careful attention:

• •Never use wildcard (*) for Access-Control-Allow-Origin on authenticated endpoints. Maintain an explicit allowlist of registered relying party domains.
• •Validate the Origin header server-side against the registered relying party registry. Do not simply reflect the Origin header back, as this effectively makes the policy a wildcard.
• •Use Access-Control-Allow-Credentials: true only when necessary, and never in combination with wildcard origins.
• •Regularly audit CORS headers across all EUDI Wallet service endpoints as part of security compliance checks.