9

It seems that most, if not all, oEmbed provider end-points do not have CORS enabled. This means I have to use JSONP (for those that support it) or go through a server proxy just to use oEmbed.

There's a corporate policy against the use of JSONP from 3rd-party providers, but I still want to leverage oEmbed in a purely client-side way (for certain providers that we trust). I understand the security implications of a CONSUMER of oEmbed and why they might not want to allow 3rd-party markup directly into their pages, but why would providers restrict this? I could just as easily have XSS vulnerabilities if I built a server proxy and didn't filter the results.

Hanson Ho
  • 91
  • 2
  • 1
    Yup. I wish they did. Slideshare provide an API with CORS disabled which makes it pretty much useless. – Jaseem Sep 14 '12 at 19:04
  • What is the point in having it in the first place if other sites that have links to the provider's resources can't use it? If it's just for internal use, then don't list yourself as supporting it on oEmbed.com, no? – Gunchars Dec 20 '16 at 21:06

1 Answers1

1

Just guessing:

It may be related to the preflight requests. The CORS spec states that client should send an additional OPTION request in many cases (basically, for anything outside a very basic GET or POST). It means that, at server-side, you will double your incoming requests just by providing CORS and maybe that extra load would be unacceptable.

Aliaksandr Sushkevich
  • 11,550
  • 7
  • 37
  • 44
Sergio Cinos
  • 746
  • 6
  • 13
  • OEmbed uses "vary basic GET" and as such the request is still going to be sent, it's just going to be declined on the client side. – Gunchars Dec 20 '16 at 21:09