网页字体文件被第三方网站跨域引用怎么办
摘要：# 网页自家字体，怎么老被“邻居”白嫖？ 你有没有遇到过这种糟心事？——自家网站精心挑选、甚至花钱购买的字体，加载起来却慢得让人心焦。一查开发者工具，好家伙，字体请求怎么跑别人家域名去了？再仔细一看，不是CDN抽风，是你的字体文件，正被一些八竿子打不着的…
网页自家字体，怎么老被“邻居”白嫖？
你有没有遇到过这种糟心事？——自家网站精心挑选、甚至花钱购买的字体，加载起来却慢得让人心焦。一查开发者工具，好家伙，字体请求怎么跑别人家域名去了？再仔细一看，不是CDN抽风，是你的字体文件，正被一些八竿子打不着的第三方网站，悄咪咪地“跨域引用”着。
说白了，就是你服务器上的 .woff、.woff2 这些字体文件，被不是你家的网页，直接写在它们的 CSS 里调用了。你这边凭空多了流量开销和服务器压力，人家倒是用你的资源，给它自己的页面省了事。
这种感觉，就像你家的水龙头，被整条街的人接了管子来免费用水，月底账单却全寄给你一样憋屈。
字体被跨域引用，到底有啥坏处？
首先，最直接的就是钱包遭殃。字体文件可不小，尤其是中文字体。如果被一个流量稍大的站盯上，你源站的出口带宽费用可能就会悄悄上涨。搞安全的朋友都知道，有些攻击就是靠消耗你资源来达成的，这算不算一种“被动DDoS”？
其次，性能受影响。你的用户打开你的网站，字体请求可能还在排队处理别人的请求呢，页面渲染自然就慢了。用户体验一差，啥都白搭。
更让人不安的是，这暴露了你的资产路径。你的字体文件URL，就这么明晃晃地摆在外面，相当于告诉别人你服务器上某个目录的结构。在安全领域，任何不必要的信息暴露，都是风险。
（我见过最离谱的一个案例，是某公司官网的专属字体，被竞争对手的产品介绍页给引用了，这找谁说理去？）
那么，怎么治？从“堵”和“导”两方面下手
别慌，这问题有得治，而且手段还不止一种。核心思路就两条：一是堵死非法引用；二是合理疏导合法需求。
第一招：祭出服务器配置大法（治本）
这招最有效，直接从服务器层面设置规则，只允许自家域名调用。
对于Nginx服务器，在你的站点配置里（通常是 nginx.conf 或对应的 site-enabled 文件），找到处理字体文件的那个 location 块，加上这么几句：
location ~* \.(woff|woff2|ttf|eot)$ {
# 允许自己家的域名
add_header Access-Control-Allow-Origin "https://www.yourdomain.com";
# 或者允许多个自家域名
# add_header Access-Control-Allow-Origin "https://www.yourdomain.com https://cdn.yourdomain.com";
add_header Access-Control-Allow-Methods GET;
expires 365d;
}关键就是那个 Access-Control-Allow-Origin 响应头。把它设置成你的域名，浏览器就会阻止其他域名的页面加载这个资源。如果你用了多个子域名（比如主站和CDN），记得都加上。
对于Apache服务器，可以在 .htaccess 文件里这么写：
<FilesMatch "\.(woff|woff2|ttf|eot)$">
Header set Access-Control-Allow-Origin "https://www.yourdomain.com"
</FilesMatch>改完配置，务必重启一下Web服务（比如 nginx -s reload），让新规则生效。
第二招：用.htaccess或防火墙规则拦截（灵活补充）
如果服务器配置你动不了（比如用的是虚拟主机），可以试试在字体文件所在的目录，放一个 .htaccess 文件，用更细致的规则来拦截：
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^https://(www\.)?yourdomain\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(woff|woff2|ttf|eot)$ - [F,L]这条规则的意思是：如果请求字体文件的来源（HTTP_REFERER）不是来自 yourdomain.com，并且来源不是空（直接访问），就直接返回403禁止访问。
不过，这招有个软肋：HTTP_REFERER 这个请求头是可以被伪造或屏蔽的，一些浏览器插件或者隐私设置也会把它关掉。所以它更适合作为辅助手段，或者对付那些不太懂技术、直接复制你CSS代码的“小白”引用者。
对于云服务用户（比如阿里云、腾讯云），也可以考虑在WAF（Web应用防火墙）里，设置一条针对字体文件路径的 “防盗链”规则，原理跟上面类似，但可能更省心。
第三招：换条路走——字体托管服务（省心之选）
如果你觉得上面这些配置太麻烦，或者字体文件本身也是从别处来的，干脆考虑换个思路：使用专业的Web字体托管服务。
比如 Google Fonts、Adobe Fonts，或者国内的一些字体服务商。你把字体上传到它们平台（或者直接用它们提供的字体），它们会生成一个专属的、带权限控制的引用链接。这样，字体文件是从它们的CDN加载的，流量算它们的，跨域问题它们也帮你处理好了。
当然，这通常适合商用字体授权清晰，或者使用开源免费字体的情况。如果是你的独家定制字体，那可能还得自己管。
第四招：终极“物理隔离”——改路径与文件名
这算是个偏方，但有时候挺管用。如果那个第三方网站是直接复制了你某个旧版页面上的绝对路径，你可以尝试：
- 把字体文件搬到服务器上一个新的、难猜的目录里。
- 甚至给文件名加点“盐”（比如
myfont-abc123.woff2），让旧链接自然失效。
然后在你自己的网站CSS里更新引用路径。这相当于把水龙头换个地方装，还把接口改了，原来的偷水管子自然就接不上了。
不过，这属于“惹不起躲得起”的补救措施，治标不治本，而且维护起来麻烦。
最后，别忘了检查一下“内鬼”
做完防护设置，别以为就高枕无忧了。我建议你定期（比如每季度）用一些在线工具或者自己写个小脚本，搜一下你那套字体文件的URL，看看互联网上还有哪些页面在引用它。
有时候，所谓的“第三方”可能就是你自家旗下早已被遗忘的某个子站点，或者某个外包团队做的宣传页，忘了更新配置。这种“内鬼”造成的资源浪费，才是最冤的。
安全防护，很多时候防的不是外部的恶意攻击，而是内部的无心之失和粗心管理。 字体跨域引用这事不大，但像一面镜子，照出的是我们对数字资产管理的细致程度。
行了，方法就是这些。赶紧去服务器上瞅一眼吧，别让自己真成了网上那个默默奉献的“字体慈善家”。