免责声明 - 做你自己的研究（可能会等待更多的答案），我不是安全专家，这只是我几分钟后想到的。
计划这是一个开放的 api
老实说，要保护东西很难，您可以尽最大努力尝试，但实际上您是在谈论让任何人通过 javascript 访问 api，您没有太多机会完全保护它。您在制作此 api 时做出的每一个决定都应该基于任何人都可以访问它的想法，除非您实施真正的身份验证方案（例如，不是自定义方案），否则不要发送任何私人数据。
如果您的数据不是那么重要，那么它是否没有得到很好的保护也没关系。
下一个从事此工作的人可能会找到完成功能的最简单方法，当您不完全了解原始计划时，许多安全漏洞来自更新系统。
基于令牌的身份验证
允许您使用您的 api 的每个站点都将一个唯一的 id (guid) 插入到具有源站点、客户端 IP 和到期日期的数据库中。根据您页面的生命周期，这可能会很快过期，但成本会更高。
当 javascript 访问您的 api 时，他们会传递此令牌，您的 api 只需检查令牌与数据库中的 ip 并确保它没有过期。
如果您可以使用某种标准形式的身份验证，可能会使用像 ASP.NET 这样的加密 cookie，那就更好了。不过，如果您是跨域的，我不相信这是可能的。
检查IP应该有助于防止中间人攻击另一个站点试图允许用户使用您的api，它不会阻止他们自己直接使用它并对信息做任何他们喜欢的事情。
您可以尝试限制您的 api 的速率，以防止其他网站使用它向其用户提供信息。这可以通过简单地限制您分发令牌的频率以及每个令牌允许发出多少请求来完成。
CORS
http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
因为您可能正在使用跨域 ajax 调用，所以您可能需要研究一种叫做 CORS 的东西。这将允许兼容的浏览器发出跨域请求，对于不支持它的浏览器，您可能需要回退到 jsonp。这也应该有助于消除支持它的浏览器中的跨站点脚本攻击。AFAIK 这是一种浏览器技术，而不是服务器技术（除了 http 标头），所以这不会阻止任何不符合此规则的客户端，但它可以帮助保护您的用户。
防止 CSRF
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF )
如果您允许更新任何数据，那么我强烈建议您考虑使用跨站点请求防伪机制。也许像 MVC 提供的令牌，您在 cookie 中（来自 api）提供唯一值，并且还要求他们在他们向 api 发布的任何帖子中将值传递回。在服务器和客户端上实现都非常简单，服务器不需要在会话中存储任何内容来执行此操作，这意味着只要 cookie 处于活动状态，它就可以工作。这使得恶意方很难让其他人对您的 api 执行请求。如果您使用表单而不是 ajax 进行任何回发，则需要确保将令牌添加到您的回发值中。请记住，这不是一种身份验证方法，而是一种尝试防止 CSRF 的方法。
您可以将其与身份验证令牌结合使用，但同样因为它依赖于发送 cookie，这可能是不可能的。
DOS 攻击
还要尝试确保 api 方法不昂贵，以帮助阻止使用大量 cpu 时间的 DOS 攻击。当然，如果有人真的想删除您的网站，他们可能仍然可以这样做，您的工作就是尝试限制他们的途径。