, which is a typical use-case for cookies, then to web-site Y those requests would seem like legitimate requests originating from your
user account – provided that you have an active session at "cplusplus.com". This could happen totally hidden, when you visit "evil.com".
I think this is not
limited to GET requests, but effects, e.g., POST requests too.
The same origin
policy prevents this kind of cross-site request forgery (CSRF) attacks. There are other anti-CSRF techniques too.
|B) The browser also stops you from accessing the document and (most) code from inside iframes. By doing this, even if we create a malicious site that has a hidden iframe with Facebook or even a banking site, and assuming we are logged into that website in another tab or have a logged in session. This prevents us from accessing critical data inside this iframe's document such as submitting a form or even stealing the cookies.|
Web-sites set the
header to indicated whether embedding in
s on other web-sites should be allowed.
|C) There are ways around this, by using HTML elements, such as; <form>,<img> tags.|
restricted by the same origin policy. I think this is mostly for "legacy compatibility" reasons.
An API server could easily "block" GET or POST requests generated via HTML
, simply by requiring a custom
header in the request. Requests lacking the custom header would be discarded by the server. With HTML
it is not
possible to add a custom header to the requests! XMLHttpRequest can
add custom headers to the request, but with XMLHttpRequest the same origin policy kicks in 😏