Support Forums

Netlify DNS - Deploy Preview and Branch Deploys


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)?

1 Like

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.)

I’m just here to add my 2¢ that we’d also really appreciate this feature. In the meantime we have solved the security aspect by pre-generating a list of 1000 netlify deploy preview urls (thankfully Auth0 doesn’t seem to have a limit on the number of allowed URLs)

By the way, Auth0 doesn’t currently support wildcards in callback URLs. Here’s the relevant forum thread on their end: https://community.auth0.com/t/how-come-allowed-web-origins-does-not-allow-wildcards/9185


Thanks for adding your voice, @bogdanspatial!

Can you share the link to the feature request here? I can’t find it.

Hi, @coreyward, the feature request is an issue on a private GitHub repo so it isn’t publicly visible. If/when the feature becomes available, we’ll post an update here.

Hey there, please increment the counter of people waiting for this feature another time for us.
Thank you.

hi there,

thanks for weighing in. Looks like this feature is still on the table. I can’t give a specific ETA but hopefully it won’t be too long.

Hi there,

Wouldn’t it be simpler to make branch deploys and deploy previews deploy to branch.myapp.netlify.app and deploy-preview-x.myapp.netlify.app instead of branch–myapp.netlify.app and deploy-preview-x–myapp.netlify.app?

Is there an ETA for this feature? This is something we need as well.

Hi, @hoangbn. The answer is actually: “No, that would be more complex not simpler.”

This all depends, of course, on how you define what “simpler” means. You example involves subdomains of subdomains of the apex domain while the current workflow is just subdomains of the apex domain (not subdomains of subdomains).

In some ways, this is simpler but in other ways it is more complex.

For example, consider SSL certificates. For the current design, if you have a wildcard SSL certificate for *.netlify.app then all these new subdomains are already included. The subdomains below would all be covered by a single SSL certificate:

  • example.netlify.app
  • branch--example.netlify.app
  • 922eb23081a6f5be3a52d873--example.netlify.app
  • deploy-preview-1--example.netlify.app

However, if we make the deploy preview URLs for the subdomain (deploy-preview-1.example.netlify.app) now we need a new SSL certificate for every site created because now we need a new SSL certificate which includes *.example.netlify.app. This is a more complex workflow when viewed from this point of view.

We do have reasons for the current design even if those reasons are not obvious from the outside.

@kflavin, the feature request being discussed here is allowing for the deploy preview URL to be a subdomain of the custom domain (not a subdomain of netlify.app but of whatever custom domain is used). I just want to be clear what “this feature” means (as this wasn’t a request for subdomains under netlify.app).

Regarding an ETA, there is no official ETA of when or if this will be available. If/when if does become possible, we will announce it here.

If there are other questions about this, please reply anytime.

Is it helpful to also add my name behind this issue? Spent a long time trying to work around this to no avail…