As far as I know, there are exemptions to that rule for things like localhost/127.0.0.1. See https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy:
- If origin’s host component is or falls within “localhost.” [RFC6761], return “Potentially Trustworthy”.
- If origin’s host component matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632], return “Potentially Trustworthy”.
External access can be solved via your own DynDNS (probably using
This leaves a couple of things unsolved:
- Users will have to use different URLs for internal (
http://localhost/) and external (
https://userid.yourddns.com/) access. Alternatively, you could use split-horizon DNS (public DNS resolves to your WAN IP, local DNS to 127.0.0.1).
- Only localhost/127.0.0.0/8 is trustworthy, so this wouldn’t work if the server is running on another IP in your LAN. Two possible solutions:
- Split-horizon DNS, like the previous example, except that your local DNS would resolve to the LAN IP.
- Use a separate DynDNS domain for LAN access (
https://internal.clientid.yourddns.com/). Resolve that IP to the server’s LAN IP. Issue a SAN certificate that covers both domains. Note: Some DNS resolvers scrub replies containing private IP addresses.