How Selenium WebDriver overcomes Same Origin Policy
First of all “Same Origin Policy” is introduced for security reason, and it ensures that content of your site will never be accessible by a script from another site. As per the policy, any code loaded within the browser can only operate within that website’s domain.
What did it do?
Same Origin policy prohibits JavaScript code from accessing elements from a domain that is different from where it was launched. Example, the HTML code in www.google.com uses a JavaScript program “testScript.js”. The same origin policy will only allow testScript.js to access pages within google.com such as google.com/mail, google.com/login, or google.com/signup. However, it cannot access pages from different sites such as yahoo.com/search or fbk.com because they belong to different domains.
This is the reason why prior to Selenium RC, testers needed to install local copies of both Selenium Core (a JavaScript program) and the webserver containing the web application being tested so they would belong to the same domain.
How it is avoided?
To avoid “Same Origin Policy” proxy injection method is used, in proxy injection mode the Selenium Server acts as a client configured HTTP proxy , which sits between the browser and application under test and then masks the AUT under a fictional URL
Selenium uses javascript to drives tests on a browser; Selenium injects its own js to the response which is returned from AUT. But there is a javascript security restriction (same-origin policy) which lets you modify HTML of a page using js only if js also originates from the same domain as HTML. This security restriction is of utmost importance but spoils the working of Selenium. This is where the Selenium server comes to play an important role.