Cross-Origin Request Sharing (CORS)

For security reasons, web browsers have built in limits on what sort of requests can be made to a given domain from a page hosted under a different domain. Since this is a common use case for IIIF (resources embedded in pages whose domains differ from that of the server), IIIF interactions are particularly susceptible to these limits.

The mechanism for determining which of these requests should be allowed or blocked is known as Cross-Origin Resource Sharing, or CORS (opens in a new tab). A full explanation of CORS is beyond the scope of this project, but the SAM deploy template contains five parameters relating to how the IIIF server handles CORS:

• CorsAllowCredentials contains the value that will be returned in the Access-Control-Allow-Credentials response header.
• CorsAllowHeaders contains the value that will be returned in the Access-Control-Allow-Headers response header.
• CorsAllowOrigin contains the value that will be returned in the Access-Control-Allow-Origin response header. In addition, a special value, REFLECT_ORIGIN, instructs the IIIF server to copy the value of the incoming request's Origin header into the Access-Control-Allow-Origin response header.
• CorsExposeHeaders contains the value that will be returned in the Access-Control-Expose-Headers response header.
• CorsMaxAge contains the value that will be returned in the Access-Control-Max-Age response header.

The default values will work in most circumstances, but if you need the IIIF server to accept requests that include credentials or other potentially sensitive information (e.g., Authorization and/or Cookie headers), you'll need to set CorsAllowOrigin to REFLECT_ORIGIN and CorsAllowCredentials to true. Other settings allow further customization.