Adobe Fonts is one of those integrations that looks trivial until your CSP starts blocking it in production.

You add the embed code, ship a strict policy, and suddenly your typography falls back to system fonts. Or worse, you loosen style-src too much just to get it working and quietly undo a big chunk of your CSP hardening.

I’ve had to clean this up more than once. The good news: Adobe Fonts usually needs only a small set of allowances. The bad news: a lot of examples online are either too broad or copy-pasted from unrelated setups.

The short version

If you load Adobe Fonts the standard way, you typically need to allow:

  • CSS from https://use.typekit.net
  • font files from https://use.typekit.net

Sometimes teams also allow https://p.typekit.net, depending on how their kit behaves.

A practical starting point looks like this:

Content-Security-Policy:
  default-src 'self';
  style-src 'self' https://use.typekit.net;
  font-src 'self' https://use.typekit.net;
  img-src 'self' data:;
  script-src 'self';
  connect-src 'self';
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';

That’s the version I’d start with before broadening anything.

How Adobe Fonts interacts with CSP

Adobe Fonts usually works like this:

  1. Your page loads a stylesheet from use.typekit.net
  2. That stylesheet defines @font-face
  3. The browser fetches font files from Adobe-controlled hosts

From a CSP perspective, this means the main directives you care about are:

  • style-src
  • font-src

If you’re new to directive behavior, https://csp-guide.com has solid explanations of how fallback and inheritance work.

The common CSP patterns

There are three realistic ways teams handle Adobe Fonts.

Option 1: Minimal allowlist for Adobe Fonts

This is the cleanest option for most sites.

Content-Security-Policy:
  default-src 'self';
  style-src 'self' https://use.typekit.net;
  font-src 'self' https://use.typekit.net;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';

Pros

  • Tight and easy to reason about
  • Keeps Adobe Fonts scoped to the directives that actually need it
  • Avoids broad https: or wildcard allowances
  • Good fit for security reviews

Cons

  • May fail if your specific Adobe Fonts kit also pulls from another Typekit host
  • Needs validation in a real browser, not just guesswork

If you want a secure default, pick this first and inspect violations before adding anything else.

Option 2: Allow both use.typekit.net and p.typekit.net

This is the “works in more environments” version.

Content-Security-Policy:
  default-src 'self';
  style-src 'self' https://use.typekit.net;
  font-src 'self' https://use.typekit.net https://p.typekit.net;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';

You may also see policies that put both hosts in style-src and font-src. I usually avoid adding hosts to directives unless I’ve actually seen requests there.

Pros

  • More resilient across Adobe Fonts kit variations
  • Reduces the chance of random production breakage
  • Still reasonably narrow

Cons

  • Slightly broader than necessary
  • Easy for teams to stop validating and just keep appending hosts forever

This is my preferred option when I don’t fully control the Adobe Fonts configuration or when multiple teams can change the kit.

Option 3: Broad host or scheme-based allowances

This is the lazy version:

Content-Security-Policy:
  default-src 'self';
  style-src 'self' https:;
  font-src 'self' https:;

Or the wildcard version:

Content-Security-Policy:
  default-src 'self';
  style-src 'self' *.typekit.net;
  font-src 'self' *.typekit.net;

Pros

  • Fast to get working
  • Fewer support tickets from people who don’t want to debug CSP

Cons

  • Way too permissive
  • Makes policy review harder
  • Encourages “just allow more stuff” behavior
  • Undercuts the point of having CSP in the first place

I’d avoid this unless you’re doing temporary triage and already have a ticket open to tighten it back down.

What about inline styles or scripts?

Adobe Fonts itself does not mean you need 'unsafe-inline' in style-src.

That’s a common mistake. Teams see fonts break, then add 'unsafe-inline', and the issue was actually a blocked external stylesheet.

Same story for scripts: the standard Adobe Fonts CSS loading path does not automatically require loosening script-src.

If you use Adobe’s JavaScript embed loader instead of a plain stylesheet include, then script-src becomes relevant. In that case, validate the exact host and keep it narrow.

For example:

<link rel="stylesheet" href="https://use.typekit.net/abcd123.css">

This generally only affects style-src and font-src.

But this pattern:

<script src="https://use.typekit.net/abcd123.js"></script>
<script>try{Typekit.load({ async: true });}catch(e){}</script>

can force you into additional script-src allowances and maybe inline script exceptions if you’re not careful. I usually prefer the stylesheet approach because it’s simpler and less likely to punch holes in CSP.

Comparing Adobe Fonts with a real production CSP

Here’s the real CSP header you provided from headertest.com:

content-security-policy:
default-src 'self' https://www.googletagmanager.com https://*.cookiebot.com https://*.google-analytics.com;
script-src 'self' 'nonce-MWFhYTE1NDQtZmM0Yy00OWI5LWJiY2YtNzRkMzIwODFjZTI5' 'strict-dynamic' https://www.googletagmanager.com https://*.cookiebot.com https://*.google-analytics.com;
style-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://*.cookiebot.com https://consent.cookiebot.com;
img-src 'self' data: https:;
font-src 'self';
connect-src 'self' https://api.headertest.com https://tallycdn.com https://or.headertest.com wss://or.headertest.com https://*.google-analytics.com https://*.googletagmanager.com https://*.cookiebot.com;
frame-src 'self' https://consentcdn.cookiebot.com;
frame-ancestors 'none';
base-uri 'self';
form-action 'self';
object-src 'none'

If this site added Adobe Fonts using the stylesheet model, the obvious blocker would be:

font-src 'self';

That would block Adobe-hosted font files.

style-src would also block the Adobe Fonts stylesheet unless the Typekit host was added.

A minimal update would look like this:

Content-Security-Policy:
  default-src 'self' https://www.googletagmanager.com https://*.cookiebot.com https://*.google-analytics.com;
  script-src 'self' 'nonce-MWFhYTE1NDQtZmM0Yy00OWI5LWJiY2YtNzRkMzIwODFjZTI5' 'strict-dynamic' https://www.googletagmanager.com https://*.cookiebot.com https://*.google-analytics.com;
  style-src 'self' 'unsafe-inline' https://www.googletagmanager.com https://*.cookiebot.com https://consent.cookiebot.com https://use.typekit.net;
  img-src 'self' data: https:;
  font-src 'self' https://use.typekit.net https://p.typekit.net;
  connect-src 'self' https://api.headertest.com https://tallycdn.com https://or.headertest.com wss://or.headertest.com https://*.google-analytics.com https://*.googletagmanager.com https://*.cookiebot.com;
  frame-src 'self' https://consentcdn.cookiebot.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  object-src 'none';

That keeps the change isolated to the directives Adobe Fonts actually needs.

Pros and cons of using Adobe Fonts under CSP

Pros

Easy to support with a strict CSP

Compared to some third-party widgets, Adobe Fonts is pretty tame. You usually only need style-src and font-src.

No need for broad script exceptions

If you use the stylesheet embed, you can often avoid touching script-src.

Predictable behavior

Once the right hosts are allowed, it tends to stay stable.

Cons

Host confusion

Teams often don’t know whether they need use.typekit.net, p.typekit.net, or both. That leads to trial-and-error policy changes.

Easy to over-permit

I’ve seen people add https: to font-src just to stop the errors. That fixes the symptom and weakens the policy.

CDN dependency

Like any hosted font service, you’re relying on third-party availability and policy compatibility.

Self-hosting fonts vs Adobe Fonts

If you want the strongest CSP story, self-hosting usually wins.

Self-hosted fonts

Content-Security-Policy:
  default-src 'self';
  style-src 'self';
  font-src 'self';

Pros

  • Tightest policy
  • No third-party font dependency
  • Easier audits and compliance reviews

Cons

  • More operational work
  • License terms may limit what you can self-host
  • You lose some convenience from Adobe’s managed service

If your security team is aggressive about third-party reduction, self-hosting is the obvious comparison point.

My recommendation

For most developer teams using Adobe Fonts, I’d choose this approach:

Content-Security-Policy:
  default-src 'self';
  style-src 'self' https://use.typekit.net;
  font-src 'self' https://use.typekit.net https://p.typekit.net;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';

Why this version?

  • It’s narrow
  • It avoids fake fixes like 'unsafe-inline'
  • It covers the common Adobe Fonts fetch paths
  • It’s easy to explain during review

Then test in report-only mode before enforcing:

Content-Security-Policy-Report-Only:
  default-src 'self';
  style-src 'self' https://use.typekit.net;
  font-src 'self' https://use.typekit.net https://p.typekit.net;
  report-to default-endpoint;

If you already have a larger production policy, don’t rewrite everything. Just add the Adobe Fonts hosts to the exact directives that need them.

That’s the whole game with CSP: small, deliberate allowances. Not “make browser errors go away.”

Final checklist

Before shipping Adobe Fonts with CSP, I’d verify these:

  • style-src allows https://use.typekit.net
  • font-src allows https://use.typekit.net
  • font-src also allows https://p.typekit.net if your kit needs it
  • no unnecessary 'unsafe-inline' was added to fix font issues
  • no unnecessary changes were made to script-src
  • the policy was tested in Report-Only first
  • browser console violations were reviewed, not guessed at

If Adobe Fonts is the only third-party asset causing CSP pain, don’t overcomplicate it. Keep the policy boring, explicit, and narrow. That’s usually the right answer.