Are there any issues with Same Origin Policy (SOP) with TOR or *.onion addresses?

I'm thinking of

  • cookies
  • Plugins (Silverlight, Flash, Java, etc)
  • Javascript
  • "with TOR" you mean using Tor to (1) do DNS resolution (2) make a TCP connection to an IPv4 address?
    – curiousguy
    Commented Jun 25, 2012 at 22:53

3 Answers 3


I haven't actually examined Tor, but theoretically there is no problem with any same-origin policy. I don't easily find any mention of problems occurring in practice, either.

Here's a sketch of the theory. The same-origin policy is tied to three values. First is the Application Layer protocol in the form of the URI protocol scheme such as "http" or such as "https" that combines HTTP with encryption via SSL/TLS. Next is another Application Layer protocol, the domain-name system DNS, in the form of the hostname. Last is one little value from the Transport Layer protocol TCP, specifically the port number. You can use the internet for years without ever noticing that port numbers are in use because most sites use the "well known" port number for each Application Layer protocol. Well known port numbers include port 80 for http and port 443 for https.

In the abstraction called the OSI Model, a Transport Layer protocol carries any Application Layer traffic without either layer caring very much about the details of what goes on in the other layer. In reality TCP doesn't really conform to the OSI Model, but for present purposes it's close enough. Tor works at the level of TCP, a Transport Layer protocol, so that's almost all that we need to say about it.

The client software that makes the connection to a Tor node creates a SOCKS proxy connection. SOCKS is an Application Layer protocol that can carry a Transport Layer protocol, specifically TCP. That really is all that we need to say about it. But I'm going to write more anyway.

Just to bolster our intuition, here's a quick description of what happens next. With the SOCKS proxy connection in place, network client software can send normal TCP traffic over that connection and into the onion-routed network. When TCP traffic enters the onion-routed network, Tor's manual says that Tor negotiates a virtual circuit, a TCP network path that is persistent (in the short term). The virtual circuit permits the normal client software's normal TCP traffic to pass right through, except for the important fact that it gets onion-routing wrapped and unwrapped around it on the way. At the exit node from the onion-routed network, the important ventriloquism effect occurs. It appears to anyone on the far side of the onion-routed network that the Tor user's software is sending and receiving at the exit node.

The recommended Tor client-side software, which is called the Tor Browser Bundle, helps to preserve anonymity by making each Tor user's client-side software practically the same. The bundle provides the NoScript extension for Firefox. This copy of NoScript is explicitly configured not to prevent sites from executing JavaScript in the browser. That gives me extra confidence that JavaScript is expected to work and therefore that there's little or no difficulty with the same-origin policy. JavaScript's same-origin policy (SOP) is actually a little more restrictive than the SOP for other web client features such as cookies and plugins, so I feel confident that they work fine, too.


The browser can't tell if .onion is a "special" tld or a "normal" one so there is no reason for him to change his SOP.

It's like asking if there is a different behavior with *.com than with *.us ;)

If you use Tor as a proxy it's just like a "normal" socks proxy. The sites should work as expected without any changes.


When browsing the Web, and in general navigating the Internet with Tor, Tor is your "virtual" ISP (with the usual issues of trust WRT your ISP: it could alter your traffic). This is the same with an VPN.

So there is no special issue here.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .