Cross-Domain Font Loading: Configuration and Practice of Access-Control-Allow-Origin Header

Overview of Cross-Domain Font Loading Issues

In modern web development, loading font resources across domains is a common requirement. When websites load fonts from different domains, browsers enforce same-origin policy restrictions for security reasons. Specifically, Firefox browser, which supports @font-face from version 3.5, does not allow cross-domain fonts by default. This means fonts must be served from the same domain (including subdomains) unless an Access-Control-Allow-Origin header is added to the font response.

CORS Mechanism and Font Loading

Cross-Origin Resource Sharing (CORS) is a mechanism that allows web application servers to instruct browsers to permit loading resources from different origins. For font files, servers need to explicitly authorize cross-domain access by setting the Access-Control-Allow-Origin header. This header informs the browser whether code from a specific origin is allowed to access the resource.

Server-Side Configuration Solution

In Apache server environments, CORS headers for font files can be configured through .htaccess files. The following configuration example demonstrates how to set headers allowing access from all domains for common font file formats:

<FilesMatch "\.(ttf|otf|eot|woff|woff2)$">
  <IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
  </IfModule>
</FilesMatch>

This configuration uses the FilesMatch directive to match all font file extensions and sets the Access-Control-Allow-Origin header value to "*" via the mod_headers module, indicating that requests from any domain are permitted to access these font resources.

Security Considerations for Font Access Control

While using the wildcard "*" can quickly resolve the issue, security considerations are important in production environments. A better approach is to restrict access to specific domains:

Header set Access-Control-Allow-Origin "https://mywebsite.example"

This configuration only allows code from the specified domain to access font resources, providing better security control. It is important to note that current CORS implementations do not support specifying multiple domains in the Access-Control-Allow-Origin header. If multiple domains need to be supported, server-side logic must dynamically check the Origin request header and set the corresponding response header.

Best Practices for CSS Font Declarations

When declaring cross-domain fonts in remote CSS files, full absolute URL paths must be used:

@font-face {
    font-family: 'LeagueGothicRegular';
    src: url('http://www.example.com/css/fonts/League_Gothic.eot?') format('eot'),
         url('http://www.example.com/css/fonts/League_Gothic.woff') format('woff'),
         url('http://www.example.com/css/fonts/League_Gothic.ttf') format('truetype'),
         url('http://www.example.com/css/fonts/League_Gothic.svg')
}

This declaration method ensures that browsers can correctly parse the complete paths of font resources, especially in cross-domain scenarios.

CORS and Cache Optimization

When a server returns an Access-Control-Allow-Origin header containing a specific domain name (rather than a wildcard), it should also include a Vary response header with the value set to Origin:

Access-Control-Allow-Origin: https://mywebsite.example
Vary: Origin

This configuration informs the browser that server responses may vary based on the value of the Origin request header, ensuring proper functioning of caching mechanisms.

Implementation Considerations

In actual deployment, it is essential to ensure that the server supports and has enabled the mod_headers module. For other server environments (such as Nginx, IIS), configuration methods differ, but the core principle remains the same—adding appropriate CORS headers to font resource responses. Additionally, developers should test compatibility across different browsers to ensure font loading functionality works correctly.