Closed janniks closed 1 year ago
I believe this header is added by Cloudflare, @CharlieC3 do you know?
@janniks @rafaelcr I add this header as a response for all of our deployed APIs; it's a good security standard to have. I've removed it for the Ordinals API, so you should be good now. Do you know if we'll be able to add this back in the future?
@CharlieC3 I think we could disable this header only for the /ordinals/inscriptions/:id/content
endpoint, right @janniks ?
Sorry, I think we can revert the change again 🙈 Turns out there's more CSP issues in browsers that we can't fix currently. But the originals ordinals.com behaves the same way (e.g. for redirects in ordinals content in iframes)
If we do need this, /content will be enough -- but for now let's revert to whatever is a good security standard again 🙏
@janniks haha reverted, thanks!
Reopening again since recursive inscriptions are becoming more popular.
Can we turn off x-frame-options: DENY
again for the /content
route (i.e. https://api.hiro.so/ordinals/v1/inscriptions/:id/content
)? CC @CharlieC3
@janniks Can you test the Ord-API in dev before I roll the change out further? In addition to removing the x-frame-options header, I also added the frame-ancestors config to the CSP, allowing only parent sites matching https://*.hiro.so
to embed iframes from that Ord-API endpoint. So this is more secure than just allowing anyone to embed the content.
I think the dev API doesn't have any inscriptions.
Hmm seems it does not. @rafaelcr Are you able to take a look at the dev Ord API deployment? Maybe it's not registered with the dev chainhooks deployment?
Resolved off Github, closing!
Forgot to mention this on the call... Currently the API (content) responds with a
x-frame-options: DENY
header. Would it be possible to disable this? I didn't find explicit mention of this header in the codebase, so it may be default fastify logic (or similar)This is needed for some iframe CSP (content security policy) changes on the frontend