这个问题可能与主观问题有关，但这不是真正的问题。
在开发网站时，您必须了解以下几点：XSS攻击，SQL注入等。
可能非常非常困难（并且需要很长时间才能编码）来保护所有潜在的攻击。
我总是试图确保我的申请，但我不知道何时停止。
让我们举个相同的例子：像Facebook这样的社交网络。 （因为银行网站必须保护其所有数据。）
我看到一些方法：
不保护XSS，SQL注入......当您信任您的用户时，这可以真正完成：私有企业的后端。但是你确保这种类型的应用程序安全吗？
仅在用户尝试访问非拥有数据时才进行安全攻击：这对我来说是最好的方法。
保护所有，所有，全部：保护所有数据（所有者与否）：用户无法破坏自己的数据和其他用户数据：这是很长的事情，它是否非常有用？
安全的常见攻击，但不能保护非常强大的攻击（因为与被黑客攻击的机会相比，代码太长了）。
好吧，我真的不知道该做什么......对我来说，我尝试做1,2,4，但我不知道这是不是很好的选择。
不保证所有数据安全是否存在可接受的风险？我可以保护所有数据但是我需要两倍的时间来编写代码吗？风险和“时间就是金钱”之间的企业方法是什么？
谢谢你分享这个，因为我觉得很多开发人员都不知道什么是好的限制。
编辑：我看到很多回复谈论XSS和SQL注入，但这不是唯一要注意的事情。
我们来一个论坛。一个线程可以写在我们是主持人的论坛中。因此，当您将数据发送到客户端视图时，您可以添加或删除此论坛的“添加”按钮。但是，当用户尝试在服务器端保存线程时，您必须检查该用户是否有权点对它（您不能信任客户端视图安全性）。
这是一个非常简单的例子，但在我的一些应用程序中，我有一个权限层次结构，这可能非常难以检查（需要大量SQL查询...）但另一方面，它真的很难找到hack（数据在客户端视图中是伪加密的，有很多数据要修改以使黑客运行，黑客需要很好地理解我的应用程序规则才能进行黑客攻击）：在这种情况下，我可以检查一下只有表面安全漏洞（非常容易入侵）或者我可以检查非常坚固的安全漏洞（但它会降低我对所有用户的性能，并且需要我很长时间才能开发）。
第二个问题是：我们是否可以“信任”（不开发一个硬性和长期的代码，这会降低性能）在客户端视图上进行非常严格的攻击？
这是另一篇关于这种黑客的帖子:(休眠和集合检查） 安全问题：如何保护从客户端到服务器的Hibernate集合？
我认为你应该尽力保护你所能做到的一切，花在这上面的时间与修复由于某人利用你留在某处的漏洞所造成的混乱所需的时间相比是无关紧要的。
无论如何，大多数事情很容易解决：
- sql注入实际上与sql无关，它只是字符串操作，所以如果你觉得不舒服，只需使用带有绑定参数的预处理语句而忘记问题
- 在将每个不受信任的数据作为输出发送出去之前，通过转义（使用htmlentities左右）很容易否定跨站点利用 - 当然这应该与广泛的数据过滤相结合，但这是一个好的开始
- 凭证窃取：永远不会存储可以提供对受保护区域的永久访问的数据 - 而是在cookie中保存用户名的哈希版本并为会话设置时间限制：这样一来，可能碰巧窃取此数据的攻击者将拥有限制访问而不是永久访问
- 从来没有想过只是因为用户登录然后他就可以信任 - 将安全规则应用于每个人
- 将从外部获得的所有内容视为具有潜在危险：即使是从中获取数据的受信任站点也可能会受到损害，您也不希望自己也陷入瘫痪 - 即使您自己的数据库可能会受到损害（特别是如果您正在共享环境）所以不要相信它的数据
当然还有更多，比如会话劫持攻击，但这些是你应该首先看到的东西。
编辑关于您的编辑：
我不确定我是否完全理解你的例子，尤其是“对客户安全的信任”。当然，所有访问受限的页面都必须先检查用户是否有权查看内容，也可以选择是否（或她）拥有正确的权限级别：所有用户都可以使用某些操作，有些其他只适用于更受限制的群体（如论坛中的版主）。所有这些控件必须在服务器端完成，因为你可以 决不 相信客户端发送给您的是什么，通过GET，POST甚至COOKIES来获取数据。这些都不是可选的。
授权用户或任何其他人都不应该“破坏数据”。我会在“用户输入的验证和卫生”下提交此文件，这是您必须经常做的事情。如果用户“破坏您的数据”的可能性很快就会发生，那么您需要验证应用中的所有输入。转义SQL查询也属于这一类，这既是安全问题，也是数据卫生问题。
您的应用中的一般安全性应该是合理的。如果您有用户管理系统，它应该正常工作。即不应该访问某些内容的用户不应该访问它。
另一个问题，直接XSS攻击，与“打破数据”无关，但与未经授权的数据访问有关。这取决于应用程序，但如果你知道XSS攻击如何工作以及如何避免它们，有什么理由吗 不 至？
综上所述：
- SQL注入，输入验证和卫生是齐头并进的，无论如何都是必须的
- 最佳实践和一点意识可以避免XSS攻击，你不需要为此做更多的额外工作
- 除此之外的任何东西，例如“主动”暴力攻击过滤器或类似的东西，确实会导致额外的工作，取决于应用程序
简单地养成坚持最佳实践的习惯在制作安全的应用程序方面有很长的路要走，为什么不呢？ :)
您需要将Web应用程序视为服务器 - 客户端体系结构。客户端可以提出问题，服务器会给出答案。问题只是一个URL，有时会附加一些POST数据。
我能有......吗 /forum/view_thread/12345/ 请？
我可以发布这个 $data 至 /forum/new_thread/ 请？
我能有......吗 /forum/admin/delete_all_users/ 请？
您的安全性不能仅依赖于客户端而不是提出正确的问题。决不。
服务器总是需要评估问题和答案 No 必要时。
所有应用程序都应具有一定程度的安全性您通常不会在Intranet网站上请求SSL，但您需要处理SQL / XSS攻击。
用户输入您的应用程序的所有数据都应由您负责。您必须确保没有人未经授权访问它。有时，“不重要”的信息可能会带来很大的安全问题，因为我们都是懒惰的人。
前段时间，一位朋友曾经经营一家游戏网站。用户创建他们的个人资料，论坛，所有这些东西。然后，有一天，有人在某处发现了SQL注入。该攻击者获取所有用户和密码信息。
没什么大不了的，对吧？我的意思是，谁关心网站中的玩家账号？但是大多数用户使用相同的用户/密码来进行MSN，Counter Strike等等。所以很快就会成为一个大问题。
底线是：所有应用程序都应该有一些安全问题。你应该看看 STRIDE 了解你的攻击媒介并采取最佳行动。
我个人更喜欢随时保护一切。这可能是一种偏执的方法，但是当我在整个互联网上看到大量的网站时，它们容易受到SQL注入甚至更简单的攻击，并且他们不会在有人“攻击”他们并窃取他们的宝贵数据之前解决它，让我非常害怕。我真的不想成为泄露密码或其他用户信息的责任人。
只要问一下有黑客经验的人来检查您的应用程序/网站。它应该让你清楚地知道什么是错的，应该更新什么。
您希望拥有强大的API端ACL。几天前，我看到一个问题，一个人已经确保了每个UI，但网站通过AJAX易受攻击，只是因为他的API（他发送请求的地方）只是信任每一个要检查的请求。我基本上可以通过这个bug拉出整个数据库。
我认为区分防止代码注入和普通数据授权是有帮助的。
在我看来，完全消除SQL注入需要一些良好的编码习惯。根本就没有借口。
XSS注入有点不同 - 我认为它总是可以防止，但如果你的应用程序具有用户生成的内容，它可能并不简单。我只是说，与SQL注入相比，保护您的应用程序免受XSS攻击可能并不简单。所以我并不是说允许XSS是可以的 - 我仍然认为没有借口允许它，如果你的应用程序围绕用户生成的内容，那么比SQL注入更难防止。
因此，SQL注入和XSS纯属技术问题 - 下一级是授权：一个屏蔽访问数据的程度如何，这与当前用户无关。在这里，我认为它确实取决于应用程序，我可以想象区分：“用户X可能看不到用户Y的任何内容”与“用户Y的数据不打扰用户X将提高可用性和制作”是有意义的应用程序使用起来更方便“。