这个CORS处理程序安全吗？
我写了这个简单的方法来处理我的简单服务器代理中的CORS。
private void handleCors(HttpServletRequest req, HttpServletResponse resp) { final String origin = req.getHeader("Origin"); if (Strings.isNullOrEmpty(origin)) { return; } if (!origin.startsWith("http://localhost:")) { return; } resp.setHeader("Access-Control-Allow-Origin", origin); resp.setHeader("Access-Control-Allow-Credentials", "true"); resp.setHeader("Access-Control-Expose-Headers", "Authorization"); resp.setHeader("Access-Control-Allow-Headers", "Authorization, Content-Type"); } 实际应用不需要它，它仅在手动测试时使用（使用ionic serve ）。 我想，这是安全的，因为除了原点是localhost之外什么都不做，但比抱歉更安全。
此外，findbugs抱怨响应分裂漏洞 。 我应该简单地使用URLEncoder.html #coding还是有更多内容？
通常会删除空格或在包含空格的情况下不添加CORS头吗？
CORS比JSONP等早期技术更安全，更灵活。
WebAPI开箱即用，可用于GET请求。 但是，一旦开始将其用于POST, PUT or DELETE操作， CORS就会启动并删除命中服务器的请求 。 CORS会停止任何跨域请求，因此如果您的api在www.myapi.com上运行并且来自www.mywebsite.com的请求进入，则请求将被删除。 这是一项安全function，可确保来自未知域的请求无法访问服务器。
如果您使用Web客户端执行ajax调用，那么还需要添加一项内容以进行ajax调用以确保所有浏览器上的CORS字。
$.support.cors = true crossDomain: true
资源链接：
如何在旧学校的WebAPI中实现跨域请求（CORS）？
但是在单行中，如果我们想说那么CORS处理程序是不安全的。 @zapl已经提供了相关信息。
现在我试图给你一些具有一些场景的攻击类型。 希望它会给你明确的信息。
CORS（In）安全性？
- CORS的不正确实现会产生一些安全问题，最常见的是在服务器头中使用通用允许符号（*）。
- 客户端不应完全信任所接收的内容，并在不进行清理的情况下评估或呈现内容，这可能会导致错误的信任。
- 允许CORS的应用程序可能容易受到CSRF攻击。
- Preflight响应的长时间缓存可能导致滥用Preflight Client Cache引起的攻击。
- 基于Origin标头的访问控制决策可能会导致漏洞，因为攻击者可能会欺骗这些漏洞。
CORS安全 – 通用允许
- 将“Access-Control-Allow-Origin”标题设置为*
- 有效地将内容转换为公共资源，允许从任何域进行访问。
场景：
攻击者可以通过诱使用户访问攻击者控制的站点，从已将此标头设置为*的Intranet站点窃取数据
在网上。当受害者导航到受攻击者控制的站点时，攻击者可以通过受害者的浏览器对其他远程应用程序执行攻击。
CORS安全 – 错位的信任
- 两个域之间的数据交换基于信任
- 如果涉及数据交换的其中一个服务器受到损害，那么CORS模型就会面临风险
场景：
- 攻击者可以破坏站点A并托管恶意内容，因为站点B信任站点A通过CORS请求发送给站点B的数据，从而导致XSS和其他攻击。
- 攻击者可能会破坏站点B并使用站点A中公开的CORSfunction来攻击站点A中的用户。
CSRF与CORS
- 服务器可以处理客户端请求以更改服务器端数据，同时validation是否已设置Origin标头
- 攻击者可以使用XHR的.withCredentials =“true”属性将任何cookie重播到受害者登录的应用程序
场景：
- 攻击者设置Origin头或使用可信站点A向站点B发送非幂等请求。
- 在查看受信任站点A时登录到站点B的受害者会导致站点B在他不知情的情况下创建用户帐户
通过CSRF攻击。
CORS – 预检响应的缓存
- Access-Control-Max-Age标头设置为较高值，允许浏览器缓存Preflight响应。
- 将预检响应缓存较长时间可能会带来安全风险。
- 如果在服务器上更改了COR访问控制策略，则浏览器仍将遵循预检结果缓存中可用的旧策略。
CORS – 基于Origin的访问控制
- Origin标头表示请求来自特定域，但不保证。
- 如果访问基于此标头，则欺骗Origin标头允许访问该页面
场景：
- 攻击者设置Origin标头以查看受限制的敏感信息
- 攻击者使用cURL设置自定义原始标题：
curl --header 'origin:http://someserver.com' http://myserver.com:90/demo/origin_spoof.php
这是一个例子。 您可以浏览此链接：
- https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007）
- HTML5 CORS的一些安全影响或如何将浏览器用作代理