Enable CORS for GitLab Pages on Gitlab.com

When I was investigating setting up Trello Power ups (https://gitlab.com/gitlab-org/gitlab-ce/issues/32042) using gitlab pages, I realized that I wasn't able to use gitlab pages because CORS was not enabled

XMLHttpRequest cannot load https://[redacted].gitlab.io/trello-power-up/manifest.json. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://trello.com' is therefore not allowed access.

Considering how GitHub pages allows all origins, we should do the same.

HTTP/1.1 200 OK
Server: GitHub.com
Date: Thu, 08 Jun 2017 19:09:56 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 56130
Last-Modified: Tue, 02 May 2017 09:38:20 GMT
Access-Control-Allow-Origin: *
Expires: Thu, 08 Jun 2017 19:19:56 GMT
Cache-Control: max-age=600
Accept-Ranges: bytes
X-GitHub-Request-Id: FEC6:1B600:DC488E:1238FD8:5939A104

changed title from Disable CORS for GitLab Pages on Gitlab.com to Enable CORS for GitLab Pages on Gitlab.com

Silly me, for some reason I thought disable instead of enable

changed the description

I think we'll be safe enabling this for pages-only if we follow simple guidelines.

• Don't dynamically generate the allowed origins, only use Access-Control-Allow-Origin: * specifically.
• Don't set Access-Control-Allow-Credentials: true.

Browsers aren't supposed to honor CORS if both of these are configured in any case.

A good summary of the dangers: http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html

@jschatz1 @briann who do I need to ping to get the ball rolling for this?

moved from gitlab-org/gitlab-ce#33494

@ClemMakesApps probably @northrup I'd like to ask some people who are more familiar with Pages for their input as well. @DouweM @rspeicher @stanhu

/cc @ayufan

I think we mostly have these CORS headers to ensure people don't somehow access the GitLab API in a harmful way. Isn't it possible for someone to include a JavaScript widget on their Pages site that attempts to make an Ajax request to the GitLab API, and the CORS header would block that? https://stackoverflow.com/a/12014554/1992201

@ClemMakesApps please create an issue with feature proposal, as this needs to be added to pages daemon, me or @nick.thomas will handle that

@ClemMakesApps I'll just move this issue to the gitlab-pages tracker ^^

changed the description

moved from gitlab-com/infrastructure#2021 (closed)

@ClemMakesApps this is easy to add, I just want to think through the implications a little more before doing it

Is there a date you need this feature by?

added Accepting Merge Requests label

mentioned in issue #57

It would be nice to have this in time for %9.4. We are building the Trello power up (javascript app) and want to have it deployed in the %9.4 milestone. If we don't have CORs enabled for gitlab pages, I'm going to have to resort to mirroring our repo to github so that I can deploy our new trello power up app in github pages.

Benefits of doing this in 9.4

• It would be nice to keep everything within GitLab
• Users who poke around the Trello integration will notice that we are dependent on GitHub pages (may lead to community conversations about why GitLab uses GitHub pages for their own stuff)

If we can't do it in %9.4, we can always migrate over from GitHub pages to GitLab pages in the future but it would be nice to skip that step all together if that's possible

I think we mostly have these CORS headers to ensure people don't somehow access the GitLab API in a harmful way. Isn't it possible for someone to include a JavaScript widget on their Pages site that attempts to make an Ajax request to the GitLab API, and the CORS header would block that? https://stackoverflow.com/a/12014554/1992201

@stanhu, how does GitHub do this?

@ClemMakesApps we're fine from that point of view - otherwise anyone could set up a web server anywhere in the world that issued some JS and the right headers, link to it, and wait for the results to roll in.

This is about what happens when someone wants access to a resource hosted on *.gitlab.io - generally .json files.

Since there's no resource-modifying endpoints, and no authentication, in the page daemon, I really can't see how this could be a problem, so let's do it.

Awesome !! @nick.thomas, so we can get this before %9.4?

@ClemMakesApps @stanhu The API shouldn't be available when using a Pages URL though? We're not talking about turning this on for GitLab.com.

I think this is just an update to the CORS header to the gitlab-haproxy project? (e.g. see https://gitlab.com/gitlab-cookbooks/gitlab-haproxy/merge_requests/56)

@stanhu That's why I was thinking at first too, but it really belongs in Pages doesn't it?

@stanhu let's make this available to everyone using Pages.

@ClemMakesApps I should be able to ensure this is done for %9.4

changed milestone to %9.4

Thanks @nick.thomas!

mentioned in merge request !33 (merged)

!33 (merged) implements this using https://github.com/rs/cors - a wonderful library I've used elsewhere in the past.

assigned to @nick.thomas

@nick.thomas @ClemMakesApps Giving this some more thought... it probably needs to be an optional setting. Otherwise we risk exposing content on internally deployed Pages instances behind a firewall.

The setting needs to have a warning that this could allow sites to pull data from instances behind network firewalls or that are otherwise isolated.

Does this mean we need to schedule for 9.5 instead since it will require some FE/BE work?

@briann if the pages instance is behind a firewall, surely the CORS headers it exposes are of no import whatsoever?

We could add a -disable-cors option, but I don't think it's necessary. We don't make this configurable for the GitLab API itself, where the stakes are far higher.

@nick.thomas A CORS header set to * would allow data from a Pages instance behind a firewall to be sent to any third-party website that knew the URL.

@briann ahhhh, I see, you're thinking about a site outside the firewall that serves JS which the browser (inside the firewall) executes, which pulls from the pages instance and exfiltrates that data back.

I'll update !33 (merged) to have -disable-cors and open an issue in gitlab-ce to allow the API to be similarly locked down.

@nick.thomas Exactly. The API wouldn't be affected by this, would it? We're not talking about enabling CORS for the GitLab instance or the API, only Pages?

@briann my point is that the GitLab API already has the CORS configuration you're raising concerns about here. I've opened https://gitlab.com/gitlab-org/gitlab-ce/issues/33743 to discuss that side of things.

-disable-cross-origin-requests is a better name

closed via merge request !33 (merged)