前端开发人员的安全性

虽然网络安全通常被认为是数据库和架构方面的，但强大的安全态势很大程度上依赖于前端开发人员领域的元素。对于某些潜在的破坏性漏洞，例如SQL 注入和跨站点脚本 (XSS)，精心设计的用户界面是第一道防线。

以下是想要为这场正义之战出力的前端开发人员需要关注的几个领域。

控制用户输入

如果开发人员构建的表单无法控制用户输入，可能会发生一系列令人抓狂的事情。为了防范注入之类的漏洞，验证或过滤用户输入至关重要。

可以通过将输入限制为已知值来验证输入，例如在表单中使用语义输入类型或与验证相关的属性。像Django这样的框架也提供了用于此目的的字段类型。可以通过删除或替换上下文危险的字符来净化数据，例如使用白名单或对输入数据进行转义。

虽然这可能不太直观，但即使是用户提交到网站上自己区域的数据也应该进行验证。MySpace 上传播速度最快的病毒之一就是Samy 蠕虫（没错，我老了），这要归功于 Samy Kamkar 能够注入到他自己个人资料页面的代码。未经彻底验证或净化，请勿将任何输入直接返回到您的网站。

有关对抗注入攻击的更多指导，请参阅OWASP 注入预防备忘单。

注意隐藏字段

添加字段type="hidden"是隐藏页面和表单中敏感数据的一种便捷方法，但不幸的是，它并不有效。借助ZapProxy之类的工具，甚至是普通网页浏览器中的检查工具，用户可以轻松点击，从而显示一些隐藏的敏感信息。隐藏复选框可以巧妙地创建纯 CSS 开关，但隐藏字段对安全性几乎没有任何帮助。

如果您必须使用隐藏字段，这里有一些有用的指导原则。

仔细考虑自动填充字段

当用户选择向您提供其个人身份信息(PII) 时，这应该是有意识的。自动填充表单字段对用户和攻击者来说都很方便。利用隐藏字段的漏洞可以窃取自动填充字段先前捕获的 PII。

许多用户甚至不知道浏览器的自动填充功能存储了哪些信息。请谨慎使用这些字段，并禁用自动填充表单来填充特别敏感的数据。

权衡风险状况及其利弊也很重要。如果您的项目必须符合WCAG标准，禁用自动完成功能可能会导致不同模式下的输入中断。更多信息，请参阅WCAG 2.1 中的 1.3.5：识别输入用途。

保持错误通用

虽然让用户知道某条数据是否存在似乎很有帮助，但这对攻击者来说也非常有利。处理帐户、电子邮件和 PII 时，最安全的做法是宁可少用（🥁）。与其返回“此帐户的密码不正确”，不如尝试使用更模糊的反馈“登录信息不正确”，并避免泄露用户名或电子邮件是否在系统中。

为了提供更有帮助的信息，请提供显眼的联系方式，以便在出现错误时联系人工。避免透露不必要的信息。即使没有其他选择，也请不要提供与用户输入非常接近的数据。

做个坏人

在考虑安全性时，退一步思考，观察显示的信息，并问问自己恶意攻击者将如何利用这些信息，会很有帮助。扮演魔鬼代言人。如果坏人看到这个页面，他们会获得哪些新信息？这个视图是否显示了任何 PII？

问问自己，页面上的所有内容对于真正的用户来说是否真的有必要。如果不是，请删除或编辑。少即是多。

安全从前门开始

如今，前端和后端的编码重叠度越来越高。为了创建一个完善且安全的应用程序，了解攻击者入侵前端的方式至关重要。