CORS 规范指出，如果请求方法和标头不简单，则发送预检 HTTP OPTIONS 请求以查看服务器是否允许该请求。
我的服务器没有响应任何 CORS 特定的标头，所以我假设这意味着请求将被拒绝。一家安全公司最近告诉我，这意味着如果我没有用 CORS 标头明确拒绝该请求，则该请求将始终被接受，但我觉得这很难相信。
此外，一些较旧的浏览器根本没有实现 CORS，所以我想知道这里是否存在安全漏洞，这些浏览器可能能够绕过 CORS 检查？还是这些浏览器总是否认一切？
摘要：我从不希望接受跨源请求。假装 CORS 不存在是否存在安全漏洞？
不，只是假装 CORS 不存在并没有安全漏洞。CORS 是一种选择加入政策。只要您的服务器从不发送任何 CORS 标头（从不选择加入），浏览器将继续使用标准的同源策略。您可以假装 CORS 不存在，以保持您的生活简单：这是一个完全合理的策略。
CORS 是可选的：如果你想要它的额外功能，你可以使用它，但也可以忽略它并且永远不要使用它。这是设计使然。其他任何事情都会很疯狂。有数以百万计的网站是在 CORS 之前编写的，并且永远不会改变。设计一个一夜之间造就所有这些网站的标准将是疯狂的。CORS 标准的编写者并不疯狂。他们没有那样做。（事实上，他们煞费苦心地不这样做！）
我怀疑与您的安全公司存在一些误解或误解（或者您的安全公司可能是错误的）。据我所知，Web 应用程序从不发送任何 CORS 标头是可以的。
也就是说，您确实需要了解 CSRF。CSRF 是网络上的一个基本漏洞（远早于 CORS，并且与 CORS 正交）。所以，请务必阅读。你会在 OWASP 网页和这个网站上找到很多关于 CSRF 的优秀资源。针对 CSRF 的标准防御是对所有可能产生副作用的 HTTP 请求使用 CSRF 令牌。
您是要保护客户端还是服务器？据我了解，CORS 旨在为客户端应用程序（例如脚本）提供一种访问“同源策略”之外的资源的方法。在没有 Access-Control-Allow-Origin HTTP 标头的情况下，符合标准的浏览器不应允许脚本检索其域之外的资源（例如通过 AJAX 请求），所以我认为您的问题的答案是您没有担心它。但是，CORS / 同源策略是由客户端强制执行的，所以我不知道你可以在服务器端做什么来拒绝跨域请求，而不是明确地允许它们使用该标头。
当您的 Web 服务器收到请求时，它只会看到客户端发送给它的内容。它没有关于浏览器中发生的事情的信息，即使根本没有浏览器（假设有人使用curl或wget发出请求）。因此，阻止 CSRF 的责任主要在于浏览器，如果任何旧浏览器不采取任何措施来阻止它，这些请求将被兑现。
有许多防止 CSRF 的技术根本不处理 CORS。最有效的 AFAIK 之一是使用 CRSF 令牌：向客户端发送一个随机令牌（将其存储在站点的 cookie 中）并期望它在您需要保护的每次提交中返回。假设您使用 SSL，攻击者（无权访问 cookie）无法知道令牌是什么，因此他无法伪造有效请求。