How the cross-site access check works

Browsers keep websites apart: a page on one site cannot read what another site sends to your visitor's browser. Sites can relax that rule with a setting called CORS, for example to let their own app on another address fetch data. Set too loosely, it lets any website read your pages through your visitors' browsers, including what they see when logged in.

What it reads

One request for your home page with an Origin header naming an outside site, https://cors-check.scanylo.com. A browser sends the same header when a page on another site asks for one of yours. The address names us, so you can tell from your logs who asked. Redirects are not followed.

What it reports

• Any outside site may read your logged-in pages: your server copies our made-up origin into Access-Control-Allow-Origin and also sends Access-Control-Allow-Credentials: true. Any website a logged-in visitor opens could then read their account pages on your site. This is serious.
• Any outside site may read your public pages: the origin is copied back, but without credentials. Only what a logged-out visitor sees can be read, so this is information, but it often means the same rule applies to other parts of the site where it matters more.

A wildcard, Access-Control-Allow-Origin: *, is not reported: browsers never send a visitor's cookies with it, so it only shares public content.

What it cannot see

• CORS rules on other addresses, such as an API under /api/ or api.yourdomain.com. The check makes one request, to the home page.
• Rules that only apply to some origins, such as a list of partner sites. A correct list is not a problem and does not show up here.

What to do with the result

Ask your developer to replace the copied origin with a fixed list of the sites that really need access, and to send Access-Control-Allow-Credentials: true only to those. Many frameworks have a CORS setting where "allow any origin" was switched on during development.