Web Font Loading Needs a Network and CSP Boundary
A web font can look like a passive design asset. The browser still has to fetch it, parse a binary file, and decide whether the response belongs to the stylesheet that requested it. CSS Fonts Level 4 defines a font fetch with a URL, a font destination, and CORS mode. The font is a network resource with a security and privacy lifecycle.
The first question is where the font comes from. A self-hosted font keeps the request path under the application's control, but it still needs an inventory of the CSS, the font binaries, the cache policy, and the server that serves them. A third-party font service creates a request from the user's browser to another origin. That request may reveal the user's network address and page context, depending on referrer and cache behavior, and it gives the provider control over the bytes that the renderer parses.
CORS is not a trust policy
The specification uses CORS for font loads. That prevents an arbitrary site from reading a cross-origin font response in the page context, but it does not prove that the provider is trustworthy, that the file has not changed, or that the font is appropriate for the application. A permissive provider can still serve content to every origin it allows.
Use a Content Security Policy font-src directive to list the origins that may supply fonts. Keep the policy as narrow as the deployment allows. If fonts are self-hosted, include only the application's asset origin and any explicitly approved CDN. A wildcard or a broad third-party allowlist turns the browser into a font loader for origins that the application does not control.
Subresource Integrity is useful for resources that the browser can verify from an integrity attribute, but CSS font loading does not make that the whole control. The application should also pin font files in its build, serve immutable versioned paths, and verify the deployed file hash. Review the font license and provenance at the same time as the technical checks. A font file from an unverified source is a parser input and a supply-chain artifact.
Review the stylesheet as code
@font-face rules can appear in first-party CSS, a theme, a plugin, or a user-editable template. Search for every remote font URL and every CSS import that can introduce one. Treat a theme upload as code review even when it contains no JavaScript. A stylesheet can cause a request to an internal host or a monitoring endpoint if the renderer follows the URL.
The unicode-range descriptor can limit which glyph ranges trigger a download, and font substitution can change the number of requests. Those behaviors matter for privacy and availability, but they are not authorization controls. Do not use them to hide a fetch from a browser monitoring tool or to assume a font will not load because the page uses only ASCII text.
Test the actual browser path
Use the browser development tools to confirm the font request URL, origin, credentials mode, redirect chain, and response headers. Test with a missing font, an expired cache entry, a blocked third-party origin, and a CSP that excludes the font. The page should fail visibly or fall back to an approved local font rather than silently contacting an unlisted host.
For an inventory, record the font family, binary hash, source URL, CSS rule, license, and owning application. A font is easy to overlook because it has no login prompt and no API key. That is exactly why it belongs in the application's asset and network-boundary review.
Top comments (0)