How to use font fingerprints for supply chain security
- Step 1Pin expected hashes — On first deploy, compute hashes for every font and store in fonts.expected.json: { 'Inter-Regular.woff2': 'abc...123' }.
- Step 2Verify on every build — CI step recomputes hashes and diffs against expected. Mismatches block the deploy until investigated. Catches both accidental updates and malicious tampering.
- Step 3Update intentionally — Bumping a font version requires updating fonts.expected.json. PR review forces explicit acknowledgement of the change. Non-explicit changes can't ship to production.
Frequently asked questions
Has there been a real font supply-chain attack?+
Less common than JavaScript supply chain attacks, but possible — and font files can carry exploits (CVE-2014-0224 affected font parsers). Best practice: treat fonts like any third-party resource and pin them.
Should I self-host to avoid supply-chain risk?+
Yes for high-security audiences. Self-hosting eliminates the third-party CDN entirely — you control every byte. Pair with the Google Fonts CSS Generator for the migration.
Is SRI sufficient on its own?+
SRI verifies at runtime in the user's browser. Build-time hash pinning catches issues before deploy. Use both: build-time for early detection, SRI for browser-side verification of correctly-signed content.
Privacy first
Every JAD Font tool runs entirely in your browser using opentype.js and the wawoff2 WASM Brotli encoder. Your fonts never leave your device — verified by zero outbound network requests during processing.