If a domain, for example foo.com is pointed to a IP address (A record) outside of my control, for example the Twitter IP address. And the domain is visited using a browser:

  • What will be displayed in the browser?
  • Does it make sense for companies to prevent establishing a connection to their sites from not controlled domains?
  • 3
    I'm not sure I understand 'Does it make sense for companies to prevent establishing a connection to their sites from not controlled domains?'. What do you want to ask with this? Is your question 'Should countermeasures be taken on the server to prevent listening to any hostname?' eg. only responding to known hosts?
    – Bob Ortiz
    Commented Nov 2, 2023 at 13:23

2 Answers 2


what will be displayed in his browser?

Either an error message or the Twitter homepage. Your browser will connect to Twitter's web server, and request the page for foo.com. The webserver can either respond that it doesn't know about foo.com, or just serve the page that it does know about.

does it make sense for companies to prevent establishing a connection to their sites from not controlled domains?

Yes, because of DNS rebinding. If foo.com always points to the Twitter, there is not much of a problem. But if foo.com first serves a malicious script and only then points to Twitter, the malicious script can access resources on Twitter. The same-origin policy works on domain names, not on IP addresses, so having a domain name point to different things can bypass the same origin policy.

In practice this is rarely exploitable, since cookies are also bound to a domain. You are logged in at twitter.com, not on foo.com, and letting foo.com point to Twitter does not give foo.com access to the cookies.

  • 2
    DNS rebinding is actually interesting. Do you know of an easy way to test this without actually claiming domains? Is the behavior the same when using the HOSTS file? Or is simply using another 'Host:' header enough?
    – Bob Ortiz
    Commented Nov 2, 2023 at 13:27
  • 2
    If twitter ignored the Host header, I could imagine tωitter.com initially pointing to the real twitter server, tricking a victim into logging in, then rebinding, allowing the attacker to steal your session cookie, since the browser would have the cookie bound to tωitter.com, not twitter.com.
    – josh3736
    Commented Nov 2, 2023 at 23:18
  • Checking the Host header is not a useful security tool, because it is trivial for an attacker to change the Host header before forwarding traffic. You would already have to do a fair bit of processing to rewrite any part of the responses that link to the "target" domain, or likely run afoul of CORS policies, cookies explicitly setting their domain, or just lose the traffic. Commented Nov 3, 2023 at 9:45
  • 4
    This answer describes HTTP behavior, however, when accessing https://foo.com then Twitter's servers can't possibly "just serve the page that it does know about" as they can't complete the TLS handshake due to a lack of a certificate for foo.com.
    – Peteris
    Commented Nov 3, 2023 at 11:13

Multiple failures will probably occur, preventing much from happening.

Many sites are behind reverse proxies (e.g. CloudFlare) or other virtual host setups that rely on looking up the backend server using the TLS SNI value and/or HTTP host header. If you connect to one of these proxies with a hostname they are not expecting, you will certainly get an error.

Additionally, even if you were able to connect to the server successfully, the browser will display a warning because the server will not provide a valid certificate for "foo.com".

You must log in to answer this question.

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