2011年，有一些博客帖子如https://www.contextis.com/resources/blog/webgl-more-webgl-security-flaws/指出了WebGL的安全漏洞。在那个时间点，似乎可以使用WebGL从WebGL的帧缓冲区范围之外获取像素数据。在Khronos安全站点上，似乎已解决此问题https://www.khronos.org/webgl/security/。他们谈论所有新的内存都被归零，这样就无法看到陈旧的数据。
简而言之，在过去的几年里，我还没有看到很多关于此事的喋喋不休，WebGL仍然不安全或者现在好转吗？目前的安全问题是什么？
答案 0 :(得分：4)
WebGL的目标始终是安全的，如您在Khronos网站的链接中所述。但是早在2011年，许多WebGL实现仍然处于起步阶段，并且有很多问题需要解决。正如你所发现的那样，有很多“天空正在下降”的博客帖子，实际上只是指出了这些早期实现中的差距。
快进到今天，我认为现代WebGL实现非常紧张。考虑到WebGL安全性的差距现在不仅仅会影响启用WebGL的页面，它会影响任何网页，因为没有什么能阻止恶意网站或注入的代码在非WebGL页面上创建WebGL上下文。浏览器供应商非常重视这一点，如果他们认为存在未解决的安全问题，则默认情况下不会启用WebGL。
许多现代实现还包含blacklists or whitelists，以确保仅在存在已知保留安全模型的驱动程序时启用WebGL。
所以是的，对于任何默认启用了WebGL的浏览器，可以安全地假设供应商对其WebGL实现的安全性充满信心。
答案 1 :(得分：4)
WebGL会做很多事情来防止任何问题。
CORS
WebGL不允许使用来自其他域的任何图像，除非该域提供跨源资源共享权限。
请注意，这与Canvas 2D API不同，它允许您使用任何图像，但如果您使用来自不同域的图像并且您没有获得CORS权限，则画布将被标记为不可读;您无法再拨打getImageData或toDataURL。
清除所有内存
WebGL清除所有缓冲区，纹理，渲染缓冲区等，因此其他程序没有剩余数据
检查所有边界
访问内存的所有函数都检查了它们的边界。您无法在纹理或缓冲区等范围之外上传数据。
强制执行着色器限制
着色器在发送给驱动程序之前进行预解析，并检查它们是否未通过某些限制。函数只能嵌套8个级别。标识符不能超过256个字符。检查并强制执行统一和属性限制。
重写所有着色器
用户提供的着色器不会直接传递给驱动程序。相反，它们是使用生成的变量名重写的，在适当的地方插入边界检查，重写表达式以解决驱动程序错误。
WebGL实现通常有黑名单
如果特定驱动程序出现问题，浏览器供应商会尝试添加变通方法或将其列入黑名单。
有些浏览器会采取更加极端的措施
Chrome（也许很快就会推出Firefox）并没有为运行网页的流程提供直接访问GPU的权限。因此，如果JavaScript中存在错误或HTML5中存在错误，该错误会导致页面运行一些代码无法访问GPU（或系统的任何其他部分）的代码。
最重要的是，在Chrome中实际访问GPU的过程无权访问GPU以外的任何内容。例如，该进程无法访问磁盘。
WebGL的设计是安全的，就像JavaScript或HTML5或图像解压缩或视频解码一样，如果有错误，浏览器会立即修复它。