[_odey]

Note: browsers also give you a Secure Context for .localhost domains.

https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

So you don't need self signed certs for HTTPS on local if you want to, for example, have a backend API and a frontend SPA running at the same time talking to eachother on your machine (authentication for example requires a secure context if doing OAuth2).

[c-hendricks]

> if you want to, for example, have a backend API and a frontend SPA running at the same time talking to eachother on your machine

Won't `localhost:3000` and `localhost:3001` also both be secure contexts? Just starting a random vite project, which opens `locahost:3000`, `window.isSecureContext` returns true.

[_odey]

This is used for scenarios where you don't want to hardcode port numbers, like when running multiple projects on your machine at the same time.

Usually you'd have a reverse proxy running on port 80 that forwards traffic to the appropoiate service, and an entry in /etc/hosts for each domain, or a catch all in dnsmasq.

Example: a docker compose setup using traefik as a reverse proxy can have all internal services running on the same port (eg. 3000) but have a different domain. The reverse proxy will then forward traffic based on Host. As long as the host is set up properly, you could have any number of backends and frontends started like this, via docker compose scaling, or by starting the services of another project. Ports won't conflict with eachother as they're only exposed internally.

Now, wether you have a use for such a setup or not is up to you.

[bolognafairy]

Well shit. TIL. Time to go reduce the complexity of our dev environment.

[jrvieira]

you should never trust browsers default behavior

1. not all browsers are the same

2. there is no official standard

3. even if there was, standards are often ignored

4. what is true today can be false tomorrow

5. this is mitigation, not security

[wutwutwat]

1. not all browsers are the same

they are all aiming to implement the same html spec

2. there is no official standard

there literally is

> A context is considered secure when it meets certain minimum standards of authentication and confidentiality defined in the Secure Contexts specification

https://w3c.github.io/webappsec-secure-contexts/

3. even if there was, standards are often ignored

major browsers wouldn't be major browsers if this was the case

4. what is true today can be false tomorrow

standards take a long time to become standard and an even longer time to be phased out. this wouldn't sneak up on anyone

5. this is mitigation, not security

this is a spec that provides a feature called "secure context". this is a security feature. it's in the name. it's in the spec.

[jrvieira]

Secure contexts, not a part of the html spec, are described in the w3c candidate recommendation, which I can assume you are calling the official standard, which states:

>5.1. Incomplete Isolation > >The secure context definition in this document does not completely isolate a "secure" view on an origin from a "non-secure" view on the same origin. Exfiltration will still be possible via increasingly esoteric mechanisms such as the contents of localStorage/sessionStorage, storage events, BroadcastChannel, and others.

>5.2. localhost > >Section 6.3 of [RFC6761] lays out the resolution of localhost. and names falling within .localhost. as special, and suggests that local resolvers SHOULD/MAY treat them specially. For better or worse, resolvers often ignore these suggestions, and will send localhost to the network for resolution in a number of circumstances. > >Given that uncertainty, user agents MAY treat localhost names as having potentially trustworthy origins if and only if they also adhere to the localhost name resolution rules spelled out in [let-localhost-be-localhost] (which boil down to ensuring that localhost never resolves to a non-loopback address).

>6. Privacy Considerations > >The secure context definition in this document does not in itself have any privacy impact. It does, however, enable other features which do have interesting privacy implications to lock themselves into contexts which ensures that specific guarantees can be made regarding integrity, authenticity, and confidentiality. > >From a privacy perspective, specification authors are encouraged to consider requiring secure contexts for the features they define.

This does not qualify as the "this" in my original comment.

[kbolino]

Notably, assuming conformance to this standard, a browser might still not treat localhost domains as trustworthy if it has reason to believe they can be resolved remotely. However, I'm not sure in what environments this is likely to be the case, especially with browsers implementing their own DNS over HTTPS.

[TingPing]

Recently browsers hardcode localhost to never resolve over dns.