REST Web 服务以及 XSS 保护的位置
我想知道我们网站中放置 XSS 防护的最佳位置在哪里。我们的团队分为前端团队和后端团队，由于我们使用不同的平台，因此我们在两个团队之间使用 REST 作为 API。我们有一个字段可以保存应该受到保护的 HTML 子集，我想知道应该在哪一层完成？
网络服务是否应该不允许它进入数据库，还是应该在退出时由消费者进行验证以确保安全？对于不能包含 HTML 的字段，我们只是保存为原始输入，并让前端在呈现之前转义它们。
我的观点是，如果有人尝试使用不允许的标签，网络服务应该响应数据无效（我们一直使用 422 来指示无效更新）。我只是想知道其他人的想法。
I am wondering where the best place to put XSS protection in our website. Our team is split up into a front end and back end teams and are using REST as an API between our two groups since we use different platforms. We have a field that could hold a subset of HTML that should be protected and I was wondering at what layer this should be done?
Should it not be allowed into the database by the webservice or should it be validated by the consumer on the way out, ensuring safety? For fields that cannot contain HTML, we are just saving as the raw input, and having the front end escape them before presentation.
My viewpoint is that the webservice should respond that the data is invalid (we have been using 422 to indicate invalid updates) if someone tries to use disallowed tags. I am just wondering what other people think.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这可能不是一个非此即彼的问题。 Web 服务可能可以从许多 UI 调用，并且 UI 会随着时间的推移而变化，因此不应假设所有调用者都是小心/可信的。确实有人可以通过手工编写查询来直接调用您的服务吗？
然而，为了可用性，我们经常选择在 UI 中进行友好的验证和错误报告。我刚刚在一个网站上填写了一份在线表格，如果任何字段包含非字母数字，该表格就会在服务层中崩溃。如果 UI 验证了输入点而不是在 3 页输入后拒绝我的请求，那就太好了。
（更不用说，如果网站要求您提供雇主的姓名，而该名称实际上包含撇号，您似乎有点受阻！）
It's probably not an either/or. The web service is potentially callable from many UIs, and Uis change over time, it should not assume that all its callers are careful/trusted. Indeed could someone invoke your service directly by hand-crafting a query?
However for the sake of usability we often choose to do friendly validation and error reporting in the UI. I've just finished filling in an online form at a web site that barfs in the service layer if any field contains a non alpha-numeric. It would have been so much nicer if the UI had validated a the point of entry rather than rejecting my request after 3 pages of input.
(Not to mention that if the web site asks you for an employer's name, and the name actually contains an apostrophe you seem a bit stymied!)
你应该同时使用两者。典型的模式是尝试在传入的数据中清理可怕的数据（如果对于给定值需要清理，您确实应该拒绝该请求）并在传出时进行编码。
前者的原因是编码有时会丢失。后者的原因是您的数据库不能被信任为数据源（人们可以在不访问您的客户端的情况下访问它，或者您的客户端可能会错过某些内容）。
You should be using both. The typical pattern is to attempt to sanitize scary data on the way in (and you should really be rejecting the request if sanitization was necessary for a given value) and encoding on the way out.
The reason for the former is that encoding sometimes gets missed. The reason for the latter is that your database cannot be trusted as a source of data (people can access it without hitting your client, or your client might have missed something).