i have some trouble tO exloit CORS respons form burp The application allowed access from the requested origin https://xrmtfgxgjkzw.com request

GET wp-json/oembed/1.0/embed?url=https%3A%2F%2Fwww.foo.com%2Fblog%2%2F HTTP/1.1
Host: www.foo.com
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Referer: https:foo.com
Cookie: TitleTrial=0; PitchTrial=0; __utma=223462276.2101520464.1484064735.1484839851.1485078453.10; __utmz=223462276.1485078453.10.4.utmcsr=fo|utmccn=(referral)|utmcmd=referral|utmcct=/fo; __distillery=8b8098c_148a7b11-3d02-465d-801a-c732e38c665f-14f1b05a3-cdd505b2b245-71f8; muxData=mux_viewer_id=2da4d2cf-1d56-4a49-9ee7-ff8da48f9416&msn=0.4423908694377975&sid=01c7e9f7-c253-4583-9e0c-89b4bbdc60b9&sst=1485078466920&sex=1485080221025; visitor_id77672=228495947; __atuvc=1%7C2%2C2%7C3; PHPSESSID=ke08cd41dm7p6dcfrfepnhat73; __utmc=223462276; __utmt=1; visitor_id77672-hash=__utmb=223462276.7.10.1485078453; pardot=had5nb89omptc2e886vpgqju83; wordpress_test_cookie=WP+Cookie+check; 
Origin: https://xrmtfgxgjkzw.com


HTTP/1.1 200 OK
Date: Sun, 22 Jan 2017 10:52:02 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.6.28
Set-Cookie: wordpressuser_7d2ee02a401bf41376509ec6471db505=+; expires=Sat, 23-Jan-2016 10:52:02 GMT; Max-Age=-31536000; path=/blog/
Set-Cookie: wordpresspass_7d2ee02a401bf41376509ec6471db505=+; expires=Sat, 23-Jan-2016 10:52:02 GMT; Max-Age=-31536000; path=/blog/
X-Content-Type-Options: nosniff
Access-Control-Expose-Headers: X-WP-Total, X-WP-TotalPages
Access-Control-Allow-Headers: Authorization
Allow: GET
Access-Control-Allow-Origin: https://xrmtfgxgjkzw.com
Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE
Access-Control-Allow-Credentials: true
Vary: Accept-Encoding,User-Agent
Content-Length: 2663
Connection: close
Content-Type: application/json; charset=UTF-8

I wonder is a vuln or not and how can`t i exploitit

2 Answers 2


https://xrmtfgxgjkzw.com is just an example generated by Burp. What it is in fact saying is that any website on the internet that the user is visiting can grab content from your site (possibly private to a user) if they are also logged into it.

Scenario is as follows:

  1. Bob logs into your site, example.com.
  2. Bob gets an email from the attacker saying he can look at some cool cat pictures at https://xrmtfgxgjkzw.com.
  3. Bob clicks and views said cat pictures.
  4. Whilst the attacker site is displaying the images to Bob, it makes some background AJAX requests to https://example.com/user/messages and reads Bob's private inbox on your site.
  5. Because the Access-Control-Allow-Origin and Access-Control-Allow-Credentials CORS headers are are set, the Same Origin Policy is not applied and allows https://xrmtfgxgjkzw.com to read the responses.

Note that the above is only a vulnerability if the headers are output on sensitive pages (i.e. those containing private user data), or pages that output secret tokens, including anti-CSRF tokens.

If there is no need to allow arbitrary origins, then you should only output the Access-Control-Allow-Origin header for origins your site trusts. If your site is self contained, then there is no need to allow any origins at all.

WordPress contains a JSON handler at /wp-json/oembed/1.0/embed?url= which is used when a link to a WordPress article is embedded in a 3rd party domain by the user (e.g. in a Facebook post). This is standard functionality of WordPress and doesn't allow access to any confidential data, however it would be better if they didn't output the Access-Control-Allow-Credentials header if not needed in case there are some undiscovered or undisclosed bugs in the handler. My best guess is this is so that authenticated content can be embedded in 3rd party domains. As the link is deemed to be secret, this prevents any random domain from requesting it. Some details here regarding oEmbed.


I have run into the same issue, and I think Wordpress is allowing this for these specific calls to allow embedding of content into other sites.

So I think this is intended functionality, and not a security bug.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .