iframe embed giving Content Security Policy error

[hq9000]

Hi all, i've embedded spotify widget to me website (iframe) but it under certain circumstances gives me the following error when I'm logged in to spotify. 

Refused to frame 'https://accounts.spotify.com/' because an ancestor violates the

following Content Security Policy directive: "frame-ancestors https://open.spotify.com".

If I log out of spotify, it starts working (showig tracks previews).

In one browser it helped me to log out/in from spotify. In another it did not.

Any idea?

[ribezaz]

Hey! How are you?

As a developer, I do believe that this error is related to Spotify's Content Security Policy (CSP) and the way Spotify handles authenticated sessions within an iframe.

When you're logged into Spotify, the player tries to access domains like https://accounts.spotify.com, but this domain doesn't allow it to be displayed in iframes from sites other than Spotify itself (due to security policy). That's why the browser blocks it and generates the error.

But why does it work when you're logged out?

Because when you're not logged in, the Spotify widget only shows previews of the tracks — and doesn't try to authenticate the user. So there's no attempt to load accounts.spotify.com and the block doesn't occur.

Possible solutions and suggestions:

Use only the preview player (unauthenticated)

If the goal is to just show songs/artists to visitors to your site, leave the iframe as is, without forcing a login. This ensures that it works for everyone, even if they are not logged in.

Avoid relying on the user's logged in session in the widget
The Spotify widget is not designed to provide a seamless login experience across domains. For custom experiences, it would be best to use Spotify's Web API with OAuth authentication, which can be done outside of the iframe.

Keep me updated if I can continue to help you.

Cheers,
ribezaz

[hq9000]

hi, thanks for a thorough answer.

1. weirdly, sometimes it DOES work even when I'm authenticated (providing full quality playback, ability to add to my playlist etc.). Why can that be? For me it suggests that the embed is actually supposed to work in this case and we are dealing with a bug or a misconfiguration on my end.

2. In general, I'd be fine with only providing preview. But how can I enforce that? For now, if a visitor happens to be an authenticated spotify user, my embed doesn't work (at least part of the time) because of content security policy?

Thanks,

[ribezaz]

For the first question about why it sometimes works when authenticated - this is likely because Spotify's authentication flow can behave inconsistently in embedded contexts. When it works while authenticated, it might be because:

The authentication token is being handled differently in certain browser sessions
Spotify might have different CSP implementations across their various subdomains
Your particular embed configuration might occasionally satisfy the security requirements

Regarding the second question about enforcing preview mode only, you have a few options:

Use the explicit preview embed URL format that Spotify provides, which looks like:
https://open.spotify.com/embed/track/ID?utm_source=generator&theme=0&preview=true
The key parameter here is preview=true which should force the preview mode.

Add parameters to disable authentication features:
https://open.spotify.com/embed/track/ID?utm_source=generator&theme=0&view=coverart
The view=coverart parameter tends to simplify the embed and reduce authentication needs.

Consider using the Spotify Web API directly instead of iframes if you need more control over the behavior, though this requires more development work.

[hq9000]

tried "preview=true" - no any effect. It does not affect the behaviour of the embed. 

Is there any documentation for this query parameters for embeds? Can you give a link?