确保Express.js REST API安全的方法是什么? [英] What are your ways of securing a Express.js REST API?
问题描述
我正在构建一个以Express.js REST API作为后端的应用程序，并且我试图将所有必要的安全措施以及要使用的库和工具都包含在内.
伙计们和gals能否总结一下您在安全保护过程的每个部分中使用的最喜欢的安全库?
也许还会写出为什么要使用自己的内容.这真的对我有很大帮助.
预先谢谢你.
I'm building an app with an Express.js REST API as the back-end and I'm trying to wrap my head around all the necessary security measures and which libraries and tools to use.
Could you guys and gals make a rundown of what your favorite and secure libraries you use for each part of the securing process are?
Maybe also write why you use the ones you use. It would really help me a lot.
Thank you in advance.
推荐答案
-
如果可以，请避免使用CORS.网络服务器发送的CORS标头告诉浏览器:减少或关闭针对跨站点/跨域攻击的内置保护，因为我(向您发送了该或那个CORS标头的网络服务器)已经加固得如此之多，以至于我不担心某些第三方脚本(例如，未从我这里下载)调用了我公开的API.这样的脚本可能是恶意的，但我不在乎".
Avoid CORS if you can. CORS headers sent by webservers tell browsers: "Water down or turn off the built-in protection against cross-site/cross-domain attacks because I (the webserver that has sent you this or that CORS header) has been hardened so much that I'm not afraid of some third-party (e.g. not downloaded from me) scripts calling the APIs which I expose. Such scripts could be malicious but I don't care".
您最好将其留给Google或Facebook之类的大公司维护的Web服务器，这样做出大胆的声明，因为它们有足够的资源来加固其Web服务器.
You better leave it to webservers maintained by big companies like Google or Facebook to make bold statements like that because they have enough resources to harden their webservers.
使用速率限制来防御L7 DoS攻击.
Use rate limiting to protect against L7 DoS attacks.
仔细检查输入.假定所有输入都是恶意的，除非您应用的检查表明不是.更具体地说，不要假设输入是有效的JSON，不要假设JSON中的数据段具有正确的JS类型，例如不要假设整数是整数或日期确实是日期.
Scrutinize input. Assume all the input is malicious unless the scrutiny you have applied shows it is not. More specifically, do not assume the input is a valid JSON, do not assume the pieces of data inside JSON have correct JS type e.g. do not assume an integer is an integer or date is indeed a date.
如果正则表达式很简单，或者您使用的正则表达式库可以通过处理输入数据来造成大量资源消耗来减轻DoS攻击的危险，则正则表达式可以帮助检查传入的请求.
Regex could be helpful to check the incoming requests provided either it is simple or you use a Regex library that mitigates the danger of a DoS attack mounted by crafting the input data to cause significant resource consumption.
即使通过防火墙也不要将Express直接暴露给Internet.使用像Nginx这样的反向代理，该代理已经过加固，可以直接连接到Internet(最好通过防火墙).使用此类代理来限制API请求的大小，允许的HTTP动词等.
Do not expose Express to Internet directly, even via a firewall. Use reverse proxy like Nginx that has been hardened to be connected directly to Internet, preferably via a firewall. Use such a proxy to clamp down on API request's size, allowed HTTP verbs, etc.
安全性必须是多层的，并在不同层中实施冗余/重复保护措施.例如，不仅要在Express中实现速率限制，而且要在Nginx中实现速率限制.
Security must be multi-layered with redundant/repetitive protective measures implemented in different layers. For example, implement rate-limiting not only in Express but also in Nginx.
使用CDN，该CDN具有针对L4 DDoS攻击的免费保护和免费的防火墙.
Use CDN which comes with complimentary protection against L4 DDoS attacks and complimentary firewall.
要进行变异(例如，更改状态的API)，请使用CSRF.CSRF攻击无法窃取任何数据，因此您不需要列出某些实体的特定API.但是如果API正在变异，例如更改服务器的状态或数据库中保存的数据，则需要CSRF.
For mutating (e.g. state-changing APIs) use CSRF. CSRF attack cannot steal any data so you don't need it for the specific API that lists some entities. But if the API is mutating e.g. changes the server's state or data held in a db then CSRF is needed.
避免在API处理程序中阻塞CPU密集型或耗时的任务.只有一个线程可以执行所有Express处理程序，因此，无论线程是被动地等待db查询完成还是忙于进行一些冗长的计算，您都无法承受在处理一个请求时阻塞它的负担.这需要以一种非阻塞的方式进行处理，这将通过使Express不太容易受到CPU耗尽攻击的影响，从而提高可伸缩性和安全性.
Avoid blocking on CPU intensive or time-consuming tasks in API handlers. There will be only one thread ever that executes all the Express handlers so you cannot afford getting it blocked on processing of one request regardless of whether the thread is passively waiting for a db query to complete or is busy doing some lengthy calculation. This needs to be handled in a non-blocking way which will improve both scalability and security by making Express less prone to CPU exhaustion attacks.
保留详细的日志(可用于取证)，如今存储很便宜.当发生运行时错误时，请记录所有血腥的细节，这些细节将带有您无法完全预测或控制的措辞.与这种方法相反，请严格控制您发送回API调用程序的错误消息的措辞/确切内容.不要包括全部细节，尤其是那些措词不详的细节，因为调用者不需要知道这些细节，并且可以促进XSS反映.
Keep detailed logs (usable for forensics), storage is cheap nowadays. When run-time errors happen, do log all the gory details which will have wording you can neither fully predict nor control. On contrary to this approach exercise tight control over the wording/exact content of the error messages you send back to the API caller. Do not include the full details, especially the ones with wording not known in advance because the caller doesn't need to know and it could facilitate XSS reflection.
请参见此.TLS终止会占用大量CPU资源，因此最好不要使用Express来处理TLS.既可以在Nginx上完成，也可以通过足够高级的防火墙来完成，也可以将证书的采购工作外包给CDN.
See this. TLS termination is CPU costly so it's better not to use Express to handle TLS. It could be done on Nginx or by a sufficiently advanced firewall or outsourced along with certificate procurement to the CDN.
在Linux上，不要以root用户身份运行Express.在Windows上，请勿使用管理帐户启动Express.使用另一个帐户，并确保该帐户除了日志目录之外，无权写入任何磁盘目录/文件.
On Linux do not run Express as root. On Windows do not start Express using administrative account. Use another account and ensure it has no permissions to write to any disk directory/file except for the logging directory.
这篇关于确保Express.js REST API安全的方法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
