许多安全措施旨在防止恶意用户滥用软件或访问他们无权访问的内容。CSRF 保护、SQLi 保护、TLS 和许多其他安全功能主要是防止恶意用户。但是，如果所有用户都可以信任呢？
假设您有一个完全内部的 Web 应用程序，它只能在公司的 Intranet 上运行，并且永远无法从外部访问。假设所有内部用户都可以信任，没有外部用户，并且应用程序内部的数据对攻击者没有多大用处。这意味着威胁模型非常有限，并且没有太多敏感数据。
考虑到这些细节，似乎一些措施，如 TLS 和 XSS 保护，不会那么重要。毕竟，攻击者拦截流量的风险很小，并且可以信任用户不会进入 XSS 有效载荷。在这种情况下，针对流量拦截或恶意用户实施安全措施是否仍然有意义？
是的。绝对没错。
您对内部网络的假设存在问题：
更一般地说，还有为什么有两套实践/标准的问题，而拥有一个适用于所有地方的单一标准肯定会更有效？
您可能会发现阅读 Google 关于 BeyondCorp 的论文很有用，https: //static.googleusercontent.com/media/research.google.com/en//pubs/archive/44860.pdf 。
tl;博士是在他们的网络概念中，您对用户和设备做出断言，而不是关于网络 - 主要是因为假设所有网络都是敌对的，而不是假设一些是敌对的，有些是敌对的不是（在某种程度上，将网络错误分类为安全的成本可能非常非常高）。
采用这种方法的一个可能原因是，斯诺登泄密事件表明，之前对其网络安全性的假设是不正确的——美国国家安全局利用光纤来接入（当时未加密的）数据中心间数据流。
我认为您问题的基本答案是安全的边界/分界点不再位于网络的边缘，而是网络上的设备。因此，将重点放在防止攻击/滥用类别上，而不是认为一个网络比另一个网络“更好”更简单，也更现实。您可能不需要像对外部 DMZ 那样对内部 DMZ 进行如此严格的控制，但假设您的网络是安全的，这是一个危险的假设。
内部网络和外部网络的攻击面不同，这意味着不同的安全措施是适当的。这并不意味着内部网络中的攻击面更小，因为一方面用户通常更受信任，另一方面有更多关键数据通常很容易从内部访问。
即使可以信任所有用户，他们的系统仍有可能感染恶意软件。除了你提到的许多攻击，如 CSRF、SQLi 或 XSS 可以跨域完成，即内部用户访问外部网站然后使用内部浏览器作为蹦床攻击内部就足够了系统。
总而言之：即使所有用户都可以信任，内部网络也需要适当的保护。如果可以从同一系统访问内部网络和 Internet，则尤其如此，因为这允许来自 Internet 的跨域攻击针对内部系统。
我会说不，主要是由于原始帖子中的引用：
没有外部用户，应用程序内部的数据对攻击者没有多大用处
主要考虑因素是，即使在内部网络中，恶意行为者仍然可以破坏可用于访问您的 Web 应用程序的系统。
我认为您的威胁模型在这里仍然是一个重要的考虑因素，尽管担心应用程序可能被入侵，但如果您保护的只是 Joe 的假期安排和 Sally 的派对邀请，那么实施 HSTS、HPKP 和 XSS 可能不值得过滤等
大多数会感染本地计算机的恶意软件不太可能被设计为运行网络扫描并查找 Intranet 网络服务器。那些，可能会寻找已知的包（尽管有些人只会寻找常见的名称，并用已知的漏洞攻击它可以找到的每一种形式）
这类似于通过默默无闻的安全性，绝对是不好的做法。然而，在许多情况下，实际问题将超过理想。不过，我仍然建议至少使用自签名证书和 HTTPS/TLS。
像这样的系统无法在有针对性的攻击中幸存下来，但是由于您已经消除了最常见的攻击面（公共互联网访问），因此大部分自动滥用不会找到您的站点。
优秀答案的一些补充：
你应该做很多事情来防止 XSS（在显示数据时正确编码数据，主要是），以防止可以由完全无辜的输入触发的各种错误（你不希望文本字段仅仅因为它包含一个<或&在错误的地方而被破坏）。这同样适用于 SQL 注入（您不希望查询中断 juste，因为字段中有引号）。所以无论如何你都需要做这些事情，即使它不是为了安全。
浏览器有一种强烈的趋势，即对非 TLS 站点的限制越来越严格，以至于它们在不久的将来可能会变得非常不可用（或者至少会显示太多警告以吓到您的用户）。
此外，即使您仅针对内部网络上的内部用户并且可以完全信任他们（请参阅其他答案以了解他们不应该这样做的原因），未来情况可能会发生变化。您可能需要向外部用户（合作伙伴、供应商、客户......）开放（部分）网站。在进行初始开发时采取正确的措施比在以后改进安全性要容易得多。