| ▲ | michaelt 6 days ago | ||||||||||||||||||||||
In the bad old days, if your company-internal tools were full of XSS bugs, fixing them wasn't a priority, because the tools could only be accessed with a login and VPN connection. So outside attackers have already been foiled, and insider threats have a million attack options anyway, what's one more? Go work on features that increase revenue instead. In principle the idea of "zero trust" was to write your internal-facing webapps to the same high standards as your externally-facing code. You don't need the VPN, because you've fixed the many XSS bugs. In practice zero trust at most companies means buying something extremely similar to a VPN. | |||||||||||||||||||||||
| ▲ | nicce 6 days ago | parent [-] | ||||||||||||||||||||||
> In principle the idea of "zero trust" was to write your internal-facing webapps to the same high standards as your externally-facing code. You don't need the VPN, because you've fixed the many XSS bugs. But why stop there? If these apps are not required to be accessed from public world, by setting up VPN you need to exploit both VPN and and the service to have an impact. Denial of specific service is harder and exploiting known CVEs is harder. | |||||||||||||||||||||||
| |||||||||||||||||||||||