Same-origin policy

#How the same-origin policy works

The table compares URLs with https://shop.example.com/.

A script can read the response to a cross-origin request only when the other server allows it. The usual way for a server to allow this is CORS.

#Why it matters for AI agents

The rule explains why a script on one site cannot read another site's data directly. A request that a site's own page makes carries that site's session. That is why requests made from inside a site's page carry the user's session context.

The rule limits reading, not sending. Agents and tools that act inside a page must still respect the rules for the origins they call.

#Wield and the same-origin policy

Wield's recipes list the https:// origins they may call. The interpreter sends requests only to those origins, and it does not follow redirects to other hosts. This is a Wield rule, enforced in code, and it is separate from the browser's rule. The browser's rule still applies to the page's own scripts.

#Related terms

• CORS
• Cookies and session
• CSRF token
• Content script

#FAQ

#What counts as the same origin?

Scheme, host and port must all match. A different subdomain is a different host, so api.example.com and shop.example.com are different origins. A different scheme, such as http instead of https, is also a different origin.

#Does the same-origin policy block sending requests?

No, not in general. A page can send a cross-origin request, and the browser sends it. The policy stops the page's script from reading the response, unless the server allows it, for example through CORS. Images and form submissions also load across origins.