Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's a lot of useful stuff to learn from this tiny example, providing you look at it more as a learning exercise than a production enterprise solution!

OP, how does this get around CORS?



The github api does not care about your origin so that wasn't something I had to deal with! If I had to deal with something like that, my best option would be to use a proxy server, which would arguably negate the whole point of this "serverless" hack.


Your browser should, though. I would expect the fetch() request from nlsn.cf to github.com to throw a security error — presumably, the way custom domains are handled on github pages includes the addition of the custom domain as a trusted source at the github end.


> Your browser should, though

It should, in the right circumstances. By default, CORS dictates that cross-origin requests should not be allowed.

But sometimes you want that to be possible, so we have headers available to is where we can signal which domains are allowed to access the origin when on another origin.

In the case of the GitHub API, they (GitHub) are setting these headers to allow any origin to access the GitHub API from any other origin, that's why your browser doesn't throw a security error. Check out the various "access-control-*" headers the GitHub API returns as response headers when you use it.

It has nothing to do with custom domains or GitHub Pages, but all to do with CORS and associated headers. You can learn more about CORS here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS


Ah, thanks. I thought they might've had a dynamic list of domains that they add each custom domain too; I guess that would be enormous, even if it sounds a lot more secure than "Access-Control-Allow-Origin: *"!


Just a CORS header.

Access-Control-Allow-Origin: star


What I meant was that GitHub's API does not check for the Host header, and the API allows connections from any source. Thus, CORS isn't an issue at all.


But the same-origin policy implemented by your browser should prevent the request before it gets anywhere near the API.


No, when a script tells a browsers to make a cross-origin request such as a GET or POST, the browser first makes a "pre-flight" request (without the payload) using the OPTIONS method to see what CORS-related response headers come back. If headers are returned that allow for it to proceed, the browser then makes whatever request the script asked for.

The network tab of developer tools should reveal all of this.


The Github API has CORS setup to allow requests from everywhere. This has nothing to do with being hosted on GitHub Pages.


> Github API has CORS setup

I know perfectly fine what you mean here, but in the name of security, it's important to be precise.

All websites and browsers have CORS, one way or another, as CORS is the general concept. By default, only "same-origin" requests are allowed and "cross-origin" requests are disabled. But CORS is still there none the less.

What GitHub has done in this case, is add support for "cross-origin" requests.

Nitpicky maybe, but thought it'd be useful to add to avoid any confusion.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: