Putting a proxy on your own hostname solves the performance problem, but you need something that parses and re-sends requests, not just a general HTTP proxy - otherwise, the third party can e.g. serve malicious Javascript code to your users within your origin.

I'm assuming this is a trusted endpoint. Either something you own or a vendor with a contract. If you're calling random endpoints from your pages, then that's another kettle of fish.

Yes, sorry for writing such a short message - I figured you were probably aware of these considerations, but I was pretty sure that not all your readers were. ;-)

Are you able to elaborate further on what attack vector you're thinking of (if only so I can google it) - JSON hijacking maybe?

The implicit assumption being that internally everything trusts the proxy?

I believe they are referring to proxying requests to third parties, rather than the first part of the post which refers to proxying to your own backend.

Proxying requests to a third-party will mean browser security features like CORS will assume they are entirely safe due to them appearing to come from your domain, and not “gist.github.com” etc.

I'm not following this. In the given example you would configure a proxy to route /api requests to your API cluster. How would an attacker inject a different backend origin?

They wouldn't, but if you proxy arbitrary requests for UnicornGifs.sexy through your CatSharing.com backend, and UnicornGifs.sexy gets owned up (or even just mischievous), it can now generate malicious content in the same origin as CatSharing.com --- the browser can't differentiate which is which. And that forged CatSharing content will be valid in any page on CatSharing.com, not just the specific pages that include it.

The point is that when you serverside-proxy requests to third parties, you're implicitly trusting the third party to control the DOM for any app in your domain.

Oh right, I missed the last sentence where OP suggested proxying to third parties.

How is that different from the unproxied scenario? If unicorngifs.sexy gets pwned, your users get pwned, whether or not there’s a proxy in the middle.

If you load javascript from there - yes, but if you iframe to there - no. You can design a solution that uses cross-origin browser protection to protect your users from getting owned in case a partner is compromised.

I think this a good interim "solution", but it won't work for everyone. On a larger scale it's rife with issues: e.g. browsers often have a limit to how many downloads they'll do from a single domain in parallel, so stuffing API, assets and pages all into the same domain can limit performance. The other thing is that using DNS to load balance between servers is much more lightweight than using an HTTP proxy / load balancer to direct traffic.

HTTP/2 virtually eliminates the limit on concurrent requests. For example Firefox allows 100 concurrent requests by default with H2.

Nobody has an excuse not to use either HTTP/2 or QUIC on a modern website.

They should also use just one domain - DNS lookups are a pretty slow and flaky part of the process of loading a webpage, and downloading loads of HTTPS certificates for all the domains involved isn't great either.

Managing just one domain is also a lot easier - less to monitor, less to maintain, simpler architecture, etc.

The only remaining reason for extra domains is to act as a security boundary - for example when you're running untrusted user javascript.

Your statements are overly definite.

> Nobody has an excuse not to use either HTTP/2 or QUIC on a modern website.

Sure they do. HTTP/2 is not uniformly superior to HTTP/1.1, primarily due to head-of-line blocking; so that on a poor quality network connection, with multiple HTTP/1.1 connections it’s quite possible that one will come through while another takes longer due to packet loss, while on HTTP/2 it’s all on one TCP connection, so that packet loss affects all requests. That’s what QUIC is about fixing. HTTP/2 is also currently incompatible with WebSockets (there’s a draft in progress for resolving that), so HTTP/2 offers no benefit for WebSocket domains or little-to-no benefit for WebSocket-heavy stuff. HTTP/2 also works differently from HTTP/1.1, so that certain moderately obscure combinations of types of long-lived requests can’t be cleanly terminated in HTTP/2 as they can be in HTTP/1.1 (sorry I’m being vague—I can’t recall the details off-hand). And there’s just the usual “existing software that doesn’t support HTTP/2” justification as well.

(Despite the listed criticisms of HTTP/2, I do agree that almost everyone should be using HTTP/2.)

As for QUIC (Google or IETF variant), it’s still experimental, with various unknowns that are being nutted out, and is not suitable for wide deployment by most entities just yet.

> The only remaining reason for extra domains is to act as a security boundary

No, that’s merely one of the best justifications for additional domains. There are other reasons for using other domains, though I would agree with a less strongly worded version of your initial declaration: that they should try, if convenient, to use just one domain.

This isn't a practical solution for embedded web servers where even six concurrent requests can be taxing.

Wouldn't it make sense to put the assets that don't need need API access on other domains?

Concurrent connections per domain is much less of an issue now. The max is high enough most apps will never hit it.

My third party requests are to a CDN. I think adding a proxy to my own domain completely defeats the point of using a CDN.

Yes, exactly. This is also very easy to implement since most webservers have a proxy like nginx. It is also very easy in Kubernetes via Ingress resource.

What if you can’t because you want to use a hosted provider for your homepage like wix? Which doesn’t support reverse producing?

The you have to deal with CORS. But any site that has real complex interactions to design around isn't going to be hosted on Wix.

Why not have your frontend proxy running somewhere else, pointing both to Wix and to the evil ad network? Wix will still think it's the host, so it should be fine.