A brief and useful content about the mechanics on Cross-Origin Read Blocking, Cross-Origin Resource Policy and Cross-Origin Resource Sharing against Meltdown, Spectre and CSRF Attacks.
CORB
By design, Cross-Origin Read Blocking validates browser requests before they even reach the server using their MIME type as a validation rule.
To enable it, send the HTTP header X-Content-Type-Options: nosniff from the server.
CORP
Cross-Origin Resource Policy is a complementary CORB mechanism for validation applied to requests flagged with no-cors to invalidate them if they came from different domains or origin.
Send the header Cross-Origin-Resource-Policy from the server with values same-origin or same-site to invalidate no-cors requests from different domains or origin.
CORS
Cross-Origin Resource Sharing is a logical context mechanism that ensures minimal security in the way that users consume web content using browsers instructing how the browser will validate the origin of the requests.
To define rules about how the origin of the request will be identified, send the HTTP header Access-Control-Allow-Origin using values like <exact_request_origin> and even a more generic approaches using *.
Conclusion
Hope that now you understand a bit better why to use these Cross-Origin Resource features
Try don't disable or ignore them in your web applications. Spectre, CSRF, and Meltdown attacks are really dangerous.
Oldest comments (5)
Meltdown and Spectre are related to hardware branch prediction. CORS, et al don't apply. They only affect shared computing environments like VPS servers and client-side JS in unpatched browsers. You can't do anything in your own code as a defense. Most major OS kernels and web browsers have already been patched to mitigate various exploit vectors.
Indeed. CORS is useful only against CSRF due to the post context. About Spectre and Meltdown not be effective through the browsers, I could not agree 100%, since just recently (2 weeks ago) Firefox released Site Isolation in a solid response for such attacks. Still, thinking about thousands of users using outdated or old browsers, create a barrier in your application is a must-have recommendation to ensure an extra layer of security until old or outdated browsers are in use. So don't ignore such features if you can.
It's not about ignoring security features in browsers. You are attempting to correlate/associate irrelevant vulnerabilities as being able to be defended against using CORS, etc. That's simply not the case and spreads misinformation.
Not sure what you are meaning about spread misinformation, but for you, CORS can't be used to defend against CSRF attacks? CORP/CORB can't be used against Spectre/Meltdown attacks? I would love to know where you're studying because my references say exactly the opposite.
Just some of my references to lead you to learn more about such a topic: