4

I'm currently experiencing an issue where base64 encoded fonts are being blocked by CSP on my website (note that I replaced the base64 with abcdefg in this example:

Refused to load the font 'data:font/woff2;base64,abcdefg///abcdefg' because it violates the following Content Security Policy directive: "font-src 'self' https://fonts.googleapis.com https://fonts.gstatic.com https://maxcdn.bootstrapcdn.com".

The fix for this is to add data: to the fonts-src directive in the content security policy, for example:

"font-src 'self' data: https://fonts.googleapis.com https://fonts.gstatic.com https://maxcdn.bootstrapcdn.com"

However, this opens my website up to data from all sources, not just the sites I have specified. I know that use of data: for default-src is deemed insecure in relation to XSS attacks, see this previous question

However what is not clear to me is if it is insecure for specifically font-src. What is the worst that could happen if I used this? Will a script kiddie convert my site into wingdings? I have found no evidence anywhere that it would have harmful effects, but at the same time it seems it is recommended everywhere with reckless abandon.

Can someone give me the definitive answer on this? And if it is indeed insecure, why is data: even a feature of CSP if it opens everyone up to accidental security incidents?

1 Answer 1

2

As you've pointed out yourself, an attacker who controls the font can deface at least parts of the website. This isn't necessarily harmless. By substituting characters, it is possible to change what a text actually says, including the labels of buttons or the displayed content of input fields. This might be used to, for example, trick a user into performing actions they didn't intend.

On the other hand, for an attacker to abuse the @font-face rule, they must already be able to manipulate a style element or attribute. You can prevent this with CSP by only allowing external style sheets loaded via HTTPS or inline styles protected with a hash. If your style sheets are vulnerable, this is a bigger issue than a @font-face injection, since there are several CSS-based attacks.

So allowing data: as a font-src is neither completely harmless nor a definite security issue. It depends on whether you prevent attacks through the other CSP directives. Of course the cleanest solution would be to load the fonts from an external source.

As to the second question: The data: source exists for the same reason that the various unsafe-* sources exist. They allow you to relax the CSP policy when the most secure options aren't possible for some reason. This is still better than no protection at all.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .