Ideally they need to divide those apps entirely; your public website doesn't need to talk to your app.

For stuff like Netflix that is truly consumer-facing, where mTLS or IP whitelisting are non-starters, the reality is you have to rethink your model entirely.

Also, I'm not sure where you got the idea I'm talking about on-prem only; this also applies to using IaaS/ cloud hosted infra.

▲

kube-system 2 hours ago | parent [-]

The reason we were talking about on-prem is because we're talking about the effort of doing these things yourself vs farming it out to a third party.

If you're a security engineer responsible for securing only:

1. a public website

2. stuff that can be ip whitelisted and/or use mTLS

Consider yourself very lucky. Most orgs need to expose a lot more than that.

▲

ang_cire an hour ago | parent [-]

Almost no companies farm their security out to third parties. The era of MSSPs is long dead, except for small non-IT businesses like mom-and-pop law firms.

> Most orgs need to expose a lot more than that.

No, in fact there are only 2 kinds of connections:

1) public, necessarily allows anonymous/unauthenticated connections

2) non-public, doesn't need to allow unauthenticated connections

Name a service, and I can tell you which one it is.

Or put another way, there are authenticated and unauthenticated services. If you can authenticate someone at the application level, you could do it at the network level.

Most places have combined them at some boundary, for ease of access, but there is no case in which an authenticated application endpoint (even /login) has to allow unauthenticated network access to it.

And in all seriousness, name a service that is not a public website, but cannot use mTLS or IP allowlisting.

SFDC? mTLS. Customer webhooks? IP whitelisting. Data warehouse? PtP VPN.

▲

kube-system an hour ago | parent [-]

> Almost no companies farm their security out to third parties.

They do it all the time, piecemeal, that's part of what anything-as-a-service delivers. If you don't want to secure an app, buy a SaaS one. Don't want to secure infrastructure?, buy an IaaS.

> Most places have combined them at some boundary, for ease of access, but there is no case in which an authenticated application endpoint (even /login) has to allow unauthenticated network access to it.

> And in all seriousness, name a service that is not a public website, but cannot use mTLS or IP allowlisting.

Literally any SaaS software where the customer does not or cannot practically install a certificate for you or provide a list of IPs in advance? mTLS is almost never used in a browser unless you are connecting to a government website with a pre-shared smartcard. IP whitelisting is great if the end users only work from behind a VPN or in an office. But there's a whole big world of people who cannot or will not do that.

	▲	ang_cire 34 minutes ago \| parent [-]
		And that is going to have to change. There are already plenty of methods that are low-impact to users, like certificate-pinning in apps, and all you have to do to make it per-user is roll in their user-specific key JIT when they download the app. Users will not be happy (just as no one is happy Reddit is going app-only), but they will do it, especially when it becomes common as companies decide they don't want to be the 5th breach notification on HN in a given day. Today we have Bun, Cursor, Northflank, and now Linode!