Get help on Discord

How to Fix a Blocked Plug-In Problem in Safari

8 replies
Last updated: Sep 28, 2020
Hey, I am hosting a pdf on sanity and put it in a link on a webpage, recently I discovered that in safari it shows 
Blocked plug-in
when clicking the link. This behavior is new to me and I do not have it with other pdf links. Does anyone have an idea why this is and what how to solve it? It is not just on my safari browser but as well on the one of my aunt (she’s the owner of the webpage I build and it already runs for almost 2 years now)
here is the part of my code:


{/*This was a test link where which works fine for me*/}
<a href="<https://blog.bernina.com/de/wp-content/uploads/sites/2/2016/07/Schnittmuster-A-kleid.pdf>" target="_blank" rel="noopener">Schnittmuster A-Kleid</a>
{/*This gives me the blocked plugin problem: */}
<a href="<https://cdn.sanity.io/files/m29pqcus/staging/d103fbd4191583b07c87301e18e1afd954e62348.pdf>" target="_blank" rel="noopener">Aktuelle Verhaltensregeln / Hygienemaßnahmen.</a>
AI Update

This is a Safari-specific security issue that's become more common with recent Safari updates. The "Blocked plug-in" error happens when Safari's security policies prevent certain content from loading, particularly PDFs served from CDNs with specific headers.

The most likely solution:

Based on the Sanity file field documentation, you can try adding a ?dl parameter to your PDF URL. According to Sanity's documentation, this parameter can be used with file assets to control download behavior:

<a 
  href="https://cdn.sanity.io/files/m29pqcus/staging/d103fbd4191583b07c87301e18e1afd954e62348.pdf?dl"
  rel="noopener"
>
  Aktuelle Verhaltensregeln / Hygienemaßnahmen.
</a>

This forces the file to download rather than trying to open inline, which may bypass Safari's plugin blocking. Note that I removed target="_blank" since forcing a download doesn't need a new tab.

Why this is happening now:

Safari has become increasingly strict with security policies over the past couple of years. Since your site has been running for 2 years without issues, it's very likely that a Safari update changed how it handles PDFs from certain CDNs. Safari's Enhanced Tracking Prevention and plugin security features have been particularly aggressive with cross-origin content.

The key difference is that your working Bernina link is likely served with different HTTP headers that Safari trusts, or it's being served from the same origin as the page itself.

Additional debugging steps:

If the ?dl parameter doesn't work, you can investigate the HTTP headers to understand what Safari is seeing:

  1. Open Safari Developer Tools (Safari → Develop → Show Web Inspector)
  2. Go to the Network tab
  3. Click your PDF link and watch the request
  4. Compare the Response Headers between the working Bernina link and your Sanity link
  5. Look specifically at Content-Type, Content-Disposition, and X-Content-Type-Options headers

If Safari continues blocking it, the issue might be related to CORS policies or how Safari interprets security headers from cdn.sanity.io. In that case, you might consider re-uploading the PDF to see if that refreshes any cached metadata, or contact Sanity support if it's a broader CDN header configuration issue.

Hi Sari, thanks for reporting this. It seems to be an issue with the Adobe plug-in and how plug-ins work in Safari in general, i.e. it’s not specific to your implementation, although that still doesn’t explain why it works with the other PDF in your code. Both links open the PDFs inside the browser, correct? And you’re not opening one of them in a separate tab but clicking both from within their own tab?

The latest versions of Safari use a new plug-in manager for enabling and disabling plug-ins on a global or per site basis. The Acrobat and Reader PDF viewer plug-ins are not trusted by default until you actively trust the plug-in globally, or for each website.
Hey
user M
no, I am just clicking on the links and both should open on the same side. one works and one doesn’t. I also thought it might be a plugin problem but I have no plugins installed (at least I couldn’t find them) and also I expected the same behaviour for both of the links. So you have any other ideas? Except to try and host the pdf somewhere else (I don’t really want to do that because then I need to figure out how to upload it there from the sanity studio.)
It seems be a common issue with some reports of it being resolved when people update Safari or Adobe Acrobat Reader, but other reports that it simply keeps showing the blocked plug-in warning.
I do see this in the console, which I’ll forward to the team just in case:

Refused to load <https://cdn.sanity.io/files/m29pqcus/staging/d103fbd4191583b07c87301e18e1afd954e62348.pdf> because it appears in neither the object-src directive nor the default-src directive of the Content Security Policy.
Shift-clicking the link to the PDF to open in new tab, or simply CMD+S to save it, should still work. It’s the preview that’s the issue in this case.
Also, you could try adding 
?dl
at the end of the URL to force a download instead of an in-line preview if that’s a workaround? 🙂
Actually, there was a recent change in our content security policy that might have been a little too strict here. This was fixed just now, but just to make sure the CDN is not serving the old CSP headers, one of our devs recommends adding 
?cache=break
temporarily:
<https://cdn.sanity.io/files/m29pqcus/staging/d103fbd4191583b07c87301e18e1afd954e62348.pdf?cache=break>
you guys are amazing! 🎉👏 I will go and implement later this evening and let you know.
Thanks for the super fast support
💚
[Edited post above for extra context]

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?