Cross-domain refers to web applications that communicate outside of their hosting domain / web server. This can be in the form of network requests to other servers or sharing data with DOM components served from different domains composed on the same web page.
The browser same-origin security policy prohibits a browser client app running in the context of one web server domain (DNS name) from communicating with, sharing data with, or reading data from browser client code running in the context of a different web server domain.
Example: Given a parent html page served from domain A.com that hosts an iframe child element whose src URL is B.com, script executing in the context of the parent html page cannot see the variables or functions defined inside the iframe, and vice versa. The parent page can write to the iframe's SRC url property, but it cannot read the property, since the URL might contain personal information.
Another example: Script running in the context of a web page served from domain A.com cannot make an XmlHttpRequest to a web service on domain B.com.
The same-origin policy requires that the URL of the requesting browser context must match the url of the target browser context in scheme, domain name, and port. Path, query, and hash tags are not considered for domain matching. Domain names must match exactly - foo.a.com cannot share data with script or DOM elements residing in bar.a.com or a.com. The browser only matches on domain name, not on IP addresses or other forms of server identity.
Some browsers support "domain lowering", or explicitly setting the domain context of a page hosted on a subdomain to a parent domain. This is useful for communicating between departmental silos in a corporate web environment but less useful for the public internet.
There are two notable exceptions to the browser same-origin security policy: <script> and <img> html tags may load data from any url. These exceptions are often at the core of legitimate cross-domain communications (such as jsonp) as well as malicious cross-site scripting attacks. Other cross-domain communication techniques include sharing data between a parent window and child iframe by writing to the iframe's window.name property (which can be read from both sides of the wall) and "pushing" data from the parent to the child iframe by writing data to the iframe's SRC url property.
Native executable browser plugins generally execute outside the browser scripting "sandbox" and are thus not held to the browser same-origin security policy. Adobe Flash and Microsoft Silverlight are both browser plugins that offer some degree of cross-domain communication through their programming APIs exposed to browser script.
The HTML 5 standard draft includes a communications section which defines a message passing API that can be used to pass data between browser script executing in different domains within the same browser, if both sides agree and cooperate to complete the exchange.
