Inquiry regarding X-Frame-Options: DENY on bitbucket.io hosting

[basictomonokai]

Recently, I noticed that my hosted pages can no longer be loaded inside an iframe on my local environment or system. The browser console displays the following error message:

"Refused to display 'https://sfosdemo.bitbucket.io/' in a frame because it set 'X-Frame-Options' to 'deny'."

It appears that the server response headers for bitbucket.io have been updated to enforce X-Frame-Options: DENY globally.

Could you please confirm if this is a recent global security update on the bitbucket.io infrastructure?

Also, is there any configuration that allows users to override this header or allow a specific domain (origin) to display the page in an iframe? For example, by using a custom configuration file or setting a specific Content-Security-Policy (CSP)?

Thank you for your assistance.

[Arkadiusz Wroblewski · Accepted solution]

Hello and welcome to Atlassian Community @basictomonokai 

Well when the server returns X-Frame-Options: DENY, the browser will block the iframe. This is enforced at the server level, meaning you cannot override it with HTML, JavaScript, or meta tags inside repository.

I'm not aware recent new Security update but I mean from security standpoint it makes sense.

Bitbucket Cloud doesn't provide a way to modify HTTP response headers or configure CSP directives. If embedding this is a requirement, you will need to host static site on a platform where you can control the response headers.

Best,

Arkadiusz 🤠

[Ben]

Hi @basictomonokai 

I have checked with our engineering team and have confirmed that a recent change was made to tighten our security posture. For this reason, loading inside of an iframe will no longer function for static hosted sites.

Thank you for your understanding.

- Ben (Bitbucket Cloud Support)

[basictomonokai]

Thank you, Ben and Arkadiusz, for the clear confirmation.

Knowing that this is a global security update for bitbucket.io, I have successfully migrated my site to my own custom domain where I can control the response headers.

I also deployed a data-rescue gateway on the old URL using window.open to help my users safely salvage their LocalStorage data.

Everything is working perfectly in the new home now. Thanks again for your support!