对于开发者而言，网络安全的重要性不言而喻。任何一处代码错误、一个依赖项漏洞或是数据库的端口暴露到公网，都会有可能直接送你上热搜。
那么，哪里可以找到详细的避雷指引呢？本文将介绍20个浏览器端安全的实操要点，让你全方位保护你的Web应用程序。各位看官，准备入坑啦！
1、用且仅用HTTPS，防范网络攻击
众所周知，一个安全的应用需要对浏览器和Web服务器之间的所有连接进行加密。此外，建议禁用一些旧的密码套件和协议。使用HTTPS时，仅加密网站的“敏感”部分是不够的。如非这样，攻击者可以截获某个未加密的HTTP请求，然后伪造来自服务器的响应，返回恶意内容。幸运的是，HTTPS目前是很容易做到的。我们可以通过LetsEncrypt免费获得证书，加上CertBot免费续期。
2、使用HSTS和预加载来保护用户免受SSL剥离攻击
服务器可以用HSTS或StrictTransportSecurityheader来强制进行加密连接。它表示需要一直使用HTTPS连接访问网站。
HSTS可以防止SSL剥离攻击。所谓的SSL剥离攻击也就是：网络上的攻击者截获浏览器发出的第一个HTTP请求（通常是未加密的），并立即伪造对该请求的回复，假装是服务器并将连接降级为明文HTTP。
值得注意的是，HSTS仅在用户至少成功访问了一次应用程序的情况下才能生效。为了克服这个限制，可以把我们的网站提交到hstspreload.org，这样，各浏览器便可以将我们的域名通过硬编码写入到HSTS列表中。
如下：
Strict-Transport-Security:max-age=;includeSubDomains;preload
警告：
在实施HSTS时，将会强制进出该网站的所有网络请求均被加密，如果网站请求中仍然有纯文本，可能无法访问。所以，先设置一个小的max-age参数进行调试，如果一切正常工作，再加大这个值。调试成功后再加上预加载(preload)，把开启预加载保留在最后一步，因为关闭它是件很麻烦和痛苦的事情。
3、设置安全Cookie，保护用户免受网络攻击
给Cookie加上Secure属性。此属性将防止Cookie在（意外或强制的）未加密的连接中泄漏。
Set-Cookie:foo=bar;...otheroptions...Secure
4、安全生成HTML以避免XSS漏洞
要避免XSS（跨站点脚本）漏洞，可以采用下面两种方法：
完全静态的网站（例如JavaScriptSPA+后端API）。避免生成HTML问题的最有效方法是根本不生成HTML，如前述方法，当然，也可以试试很酷的NexJS。模板引擎。针对传统的Web应用程序，其中的HTML大多是在后端服务器上根据提供参数动态生成的。这种情况下，不要通过字符串连接来创建HTML。推荐的做法是使用模板引擎，比如PHP语言的Twig、Java语言的Thymeleaf、Python语言的Jinja2等等。此外，务必要正确配置模板引擎，从而可以自动对参数进行编码，并且不要使用任何可以绕过这种编码的“不安全”函数。不要把HTML放在回调函数、属性（不带引号）或href/src等诸如此类的地方。
5、安全使用JavaScript以避免XSS漏洞
要避免JavaScript端的XSS（跨站点脚本）漏洞，切忌将不受信任的数据传递到可执行代码的函数或属性中。这类常见的函数或属性包括：
eval、setTimeout、setInterval等。innerHTML，ReactsdangerouslySetInnerHTML等。onClick、onMouseEnter、onError等。href、src等。location,location.href等。6、沙箱处理不可信内容，避免XSS漏洞
最好是能避免不可信的内容，但往往又不能完全避免：例如需要从远程获取HTML进行展示，或者需要允许用户用所见即所得的编辑器写文章，等等。
要避免这些场景中的XSS（跨站点脚本）漏洞，请首先使用DOMPurify清理内容，然后在沙箱中进行内容呈现。
即使所见即所得的编辑库声称从HTML中移除了恶意内容，仍然可以通过重新净化和沙箱来处理，进一步确保安全。
还有一种常见的情况是，我们想在网页上展示广告等内容。这种情况下简单采用IFrame是不够的，因为same-origin策略会允许跨域的frame将父级frame（也就是我们的网站）的URL修改为一个钓鱼网站。因此，要记住使用IFrame的沙箱属性来避免此种情况的发生。
7、采用内容安全策略，避免XSS漏洞
内容安全策略（CSP）可以很好地防御XSS（跨站点脚本）攻击、点击劫持攻击等。所以，一定要用它！默认情况下，CSP会阻止几乎所有的危险操作，所以额外的配置越少越好。如下：
Content-Security-Policy:default-srcself;form-actionself;object-srcnone它允许从Web应用程序的源代码加载脚本、样式、图像、字体等，但不允许加载其他内容。最值得注意的是，它将阻止内联脚本（）的运行，从而更好地预防XSS漏洞。
此外，form-action:self指令可防止在网站上创建恶意HTML表单（比如“您的会话已过期，请在此处输入密码”类似的表单），并将其提交到攻击者的服务器。
无论如何，都不要指定script-src:unsafeinline，一旦这样做，CSP将形同虚设。
最后，如果你担心CSP会影响生产环境，可以先以Report-Only模式进行部署：
Content-Security-Policy-Report-Only:default-srcself;form-actionself
8、设置HttpOnly的Cookie，保护用户免受XSS攻击
为Cookie设置HttpOnly属性，可以防止Cookie被JavaScript代码访问。一旦跨脚本攻击发生，该设置也会让黑客更难窃取到Cookie信息。当然，有些需要被JavaScript代码访问的Cookie，就不能做这个设置了。
Set-Cookie:foo=bar;...otheroptions...HttpOnly
9、针对下载功能，合理设置避免XSS漏洞
向用户提供下载功能时，在header中设置Content-Disposition:attachment，从而避免XSS漏洞。该设置将禁止在用户浏览器直接渲染文件，从而避免HTML或SVG格式的下载文件可能引发的漏洞。如下：
Content-Disposition:attachment;filename=document.pdf
假如我们想允许特定的文件（如pdf）能在浏览器端打开，并且也确定这样是安全的，那么，可以针对该类型文件，将header省略掉或是将attachment换为inline。
10、针对API响应，合理设置避免XSS漏洞
反射型文件下载（RFD）攻击往往通过构建一个URL从API下载一个恶意文件来实现。针对该类漏洞，可采用在APIHTTP响应中返回带有安全文件名的Content-Dispositionheader来防御。
11、利用现有平台的反跨站请求伪造（CSRF）机制，避免CSRF漏洞
为避免反跨站请求伪造漏洞，务必确保我们所采用的平台开启了反跨站请求伪造功能，并确保该配置发挥了应有的作用。
12、验证OAuth身份认证的state参数，避免CSRF漏洞
有一类与OAuth身份认证相关的跨站请求伪造漏洞是黑客让用户不经意间采用其账户进行登录。因此，如果有使用OAuth身份认证，务必确保对状态（state）参数的验证。
13、正确使用HTTP协议，避免CSRF漏洞
除了POST、PUT、PATCH、DELETE以外，不要使用其它HTTP方法进行数据更改。GET请求一般是不包含在反跨站请求伪造机制中的。
14、为Cookie设置同源属性，避免CSRF、XS-leak、XSS漏洞
为Cookie设置SameSite属性。SameSite能防止大多数的跨站点请求伪造攻击，而且还可以防止许多跨站点泄漏的漏洞。
SameSite属性有两种模式：宽松（lax）和严格（strict）。
宽松模式可以防止大多数跨站点计时和跨站点请求伪造攻击，但对基于Get请求的跨站点请求伪造漏洞无效。如下：
Set-Cookie:foo=bar;...otheroptions...SameSite=Lax
严格模式则可以防止该类基于Get请求的漏洞，以及反射型的跨站点脚本漏洞。然而，严格模式不适合常规的应用程序，因为它会中断身份验证链接。如果用户已登录某个网站，现在要在新的页面打开指向该应用程序的链接，则打开的新页面将不会为该用户自动登录。由于严格模式的限制，会话Cookie也不会随请求一起发送。严格模式设置如下：
Set-Cookie:foo=bar;...otheroptions...SameSite=Strict
15、每次登录创建一个新的会话ID，防止会话固定攻击
会话固定攻击一般是在以下情形发生：
攻击者将Cookie（例如JSESSIONID=ABC）注入到用户的浏览器中。不用担心，攻击者有很多方法可以做到这一点。用户使用其凭据登录，并在登录请求中提交攻击者设置的JSESSIONID=ABC应用程序对Cookie和用户进行身份验证。与此同时，拥有该Cookie的攻击者也就可以通过该用户的身份进行登录了。为了防止出现这种情况，程序中需要在身份验证通过后，创建一个新的会话ID返回给用户，而不是验证可能被动了手脚的Cookie。
16、合理命名Cookie，防止会话固定攻击
难道Cookie命名也能影响到网络应用程序的安全性？确实如此！将Cookie采用__Host-**的形式来命名，浏览器将：
不能通过非加密的链接访问该项Cookie，从而避免会话固定攻击以及其它涉及到Cookie读取与写入的攻击；不允许子域名重写该项Cookie，从而避免来自子域名网站（抑或是被攻陷，抑或本身就是恶意的）的攻击。该项设置示例如下：
Set-Cookie:__Host-foo=bar...otheroptions...
17、设置Cache-Controlheader，防止用户信息被窃取
缓存是将访问过的网站、下载过的文件全部存储在硬盘的某个位置，直到有人手动删除它们。默认情况下，浏览器会对页面的一切内容进行缓存，从而加快访问速度、节约网络带宽。
要在公共网络环境保证信息安全，我们需要将所有HTTP响应设置一个合适的Cache-Controlheader，特别是针对非公开的和动态的内容。
该项设置示例如下：
Cache-Control:no-store,max-age=0
18、设置Clear-Site-Dataheader，防止用户信息被窃取
另外一个可以有效保证用户退出后记录即被清除的header是Clear-Site-Data。当用户退出登录时，可以在HTTP请求中携带该header。浏览器会清除该域名下的缓存、Cookie、存储以及执行上下文。大部分浏览器都支持该header。
该项设置示例如下：
Clear-Site-Data:*
19、妥当地处理“退出”，防止用户信息被窃取
用户退出登录后，务必要对访问令牌和会话识别码进行失效处理。这样，即使攻击者从访问历史/缓存/内存等地方获取到这些信息，它们也不再有效。
此外，如果有单点登录，切记要调用单点登录的退出端口。否则，因为单点登录会话仍处于活跃状态，此时的退出将会无效，只要用户再次点击“登录”，即可自动登录。
最后，清理掉你可能用到过的Cookie、HTML5存储等。上面提到的Clear-Site-Data还未被某些浏览器支持，所以最好还是手工清除一下。
20、针对JavaScript密码采用SessionStorage，防止用户信息被后来者窃取
SessionStorage类似于LocalStorage，但对每个标签页都是独有的，而且在浏览器/标签页关闭以后将自动清除。
注意：如果要在系统内打开的多个标签页之间同步用户的授权信息，那就需要用事件来同步sessionStorage信息。