Netlify DNS - Deploy Preview and Branch Deploys

Hello!

We have a couple of front end projects we’d like to migrate to Netlify.
The problem is that our API has a CORS policy that only allows requests from specific domains, therefore we can’t use features such as deploy previews because the requests would come from deploy-preview-****.netlify.com.

Adding the Netlify domain to our CORS policy is not an option, since it is not secure.

Our solution for this problem would be to purchase another domain through Netlify’s DNS (e.g. ourdomain.com) and add it to our CORS policy. Its sole purpose would be branch deploys and deploy previews for all sites in our account.

However, we’d like to keep different “Primary domain” and “Domain alias” as the domains for production branches of each site (currently set to custom domains that are managed in another domain registrar).

Would all deploy previews and branch deploys, for all sites in our account, be available though this purchased domain (i.e. deploy-preview-****.ourdomain.com)?

Hi @Cobli_Tech,

Deploy Previews will always be on the *.netlify.com domain, but branch deploys can have subdomains on your own custom domain. Can you dynamically set the value of Access-Control-Allow-Origin so that anything that any domain that ends in your-netlify-subdomain.netlify.com is allowed? That would be the simplest path.

Thats totally insecure. I mean anyone can make a second app with attack-your-netlify-subdomain.netlify.com, right? Any code executed there could then access the API. I have the same problem for rerouting users after login with auth0 to https://preview-234-my-app.netlify.com/callback. I could allow https://*-my-app.netlify.com/callback as a redirect url but then someone can setup https://attack-my-app.netlify.com to phish my users access tokens…

You need to enable branch deploy urls that end on the domain of the project as OP requested. Currently I cannot preview my FE client against the production auth service or as such production backend.

Hi @Levino , Netlify site subdomains are unique, so if you have a site with my-site.netlify.com then ONLY your sites branch deploys and deploy previews will include my-site.netlify.com as part of the URL. Others can’t name their site the same as yours so they can’t use your sites deploy previews.

So this is the netlify url of my companies homepage: https://hardfork-hp-gatsby.netlify.com and with another account I just created this “attackers page”: https://pwnd-hardfork-hp-gatsby.netlify.com/. If I now open a PR for the attackers page I get https://deploy-preview-2–pwnd-hardfork-hp-gatsby.netlify.com/ So if I would allow https://deploy-preview*hardfork-hp-gatsby.netlify.com/callback for the auth0 callback urls then the attacker can fish my users token. I might be safe if I only allow https://deploy-preview-[uptofournumbers]-hardfork-hp-gatsby.netlify.com/callback but I think that is not possible with auth0. Also that is a super fragile “protection” (where is all this stuff documented anyhow? who says it will not change in the future). If instead I could get deployment previews from my own domain, I would immediatly be safe with https://*.hardfork.io/callback.

A few things going on here to protect you:

  1. *.netlify.com is on the public suffix list, meaning that your browser does NOT allow cross-subdomain cookies between your two example sites. I think if you try to exploit it, you’ll see that the cookie (where I presume you/Auth0 store the token) is NOT portable - even between deploy-preview-x–yoursite.netlify.com and yoursite.netlify.com and branchname–yoursite.netlify.com).

  2. CORS is the other help, of course, and you can configure that via our custom headers facility. You do have to be careful to allow specifically the names you want, as you mention. But I think that #1 above is the major, strong protection you need and it is automatic.

The feature request to allow deploy previous on your own domain is another good one and I’ve added you to the list of folks asking for it, though we previously decided not to implement it I’ve heard rumblings that it might be back on the table lately :slight_smile:

In the meantime you can of course also not use deploy previews but branch deploys with branch subdomains to host e.g. staging.yourdomain.com in a more controlled namespace.

Let me know if that doesn’t sound reasonable!

This is not about cookies / CSRF. It is about getting the auth token safely in the first place. Please carefully read what this is about. It is about the allowed redirect URLs from the auth provider.

I think my comments are relevant, though indeed, they don’t solve the problem you mention.

You clearly shouldn’t enable that kind of CORS access (deploy-preview-*sitename.netlify.com) for applications like the one you describe; you should test only on branch subdomains as I mentioned.

Thank you for your reply. I already know that I can create by hand to a subdomain and then I could add this subdomain as a redirect URL for the login flow and it would be secure. But I would have to do this manual procedure for every pull request. And why do I have to do it so insanely inefficiently? Because you (netlify) refuse to give us automatic deploy preview urls ending on our own domain (and as far as I can tell there is no technical reason for it other than maybe some technical debt that you have).

That is the whole point of this discussion. It is not a question on “how can I make this secure?”. It is a plea for: “please provide this basic functionality to end our misery!”.

This makes sense, @Levino. I also agree that these alternatives are not ideal and only workarounds. We wouldn’t have a feature request filed for this if the workarounds were perfect. :slight_smile:

We are not trying to argue with the proposed feature being a good idea. I do believe it is a great idea. (My guess is that all of our support team agrees this is a good idea but I don’t want to speak for others.)

We are only suggesting workarounds because the feature doesn’t exist yet. We are not saying “no”. Instead, we are saying “these are the options today”.

The feature request is cross-linked to this community topic and if/when it becomes available we will update this topic to let people know about it. (Also, please feel free to click the tracking button on the thread to be sure you will be emailed about any updates here.)