I totally understand the basis of origin policy and the reasoning why all modern browsers have put this policy into place.

My question I guess is, do older browsers support this, and if they don't, could mean that people can create AJAX requests and target these requests to my website using an older browser?

The reason I ask is because I don't want anybody overhauling my website with AJAX requests.

  • 1
    Could you clarify what you mean by "overhauling my site"? Are you concerned that a site will perform a cross-origin Ajax fetch of your site, overhaul the appearance, and present the altered version to the user? Or are you concerned about a large number of requests overwhelming your site? The first case is much more applicable to SOP concerns, but I now suspect the second case is closer to what you meant. (As noted below, any group of machines capable of participating in network activity could overwhelm your site.) – apsillers Oct 1 '13 at 15:21
  • I just don't want anybody being able to constantly make ajax requests from other websites because I am limited to bandwidth and I don't want any server issues due to a lot of requests from a lot of sources. – Peter Stuart Oct 1 '13 at 20:00

The same-origin policy is a client-enforced restriction. Certainly, it's possible for a particular client to fail to enforce this restriction. Note that doing so would bring the client out of compliance with W3C standards for the XMLHttpRequest API and iframe behavior.

Note that any program that can formulate an HTTP request can send a request to your site. The danger in violating the same-origin policy is to users, not to your site. Ajax requests send authentication cookies, so if a foreign site could, e.g., fetch the contents of mail.google.com while your browser is logged into Gmail, that foreign site could read your mail. The risk is not that a cross-origin request could reach your site, but that a response from your site could be read by a cross-origin site.

For example, anyone can launch an attack against a site with netcat by repeatedly doing something like:

echo "GET /index.html HTTP/1.0" | nc example.com 80

thereby flooding the site with TCP requests that each contain an HTTP request. It's easy (easier, in fact) to do the same with any dedicated tool for sending HTTP requests like cURL or wget.

If I've misunderstood your question, and you really are concerned for the user: Wikipedia makes the unsourced claim that Netscape Navigator 2.0 (released 18 years ago) supported the SOP, and this help forum post asks about how to circumvent the SOP in IE4 (released 16 years ago), so we can be certain that SOP enforcement has been around quite a while; any browser old enough to omit SOP enforcement probably has many other major holes in it, and you probably shouldn't expend too much effort trying to protect users who use a decades-old browser.

  • Thanks for your help. It's just shed some light! I think the best thing to do is to test and make old browser restrictions! – Peter Stuart Oct 1 '13 at 14:48
  • @PeterStuart That's incorrect, and I hope that you didn't get this idea from the answer. It certainly has failed to highlight a very important aspect of the problem, that this issue is a server-side issue. No browser restrictions will achieve your goals in this case. – Adi Oct 1 '13 at 15:05
  • @PeterStuart I initially misunderstood your threat model, and have added an additional paragraph. Assuming the SOP will protect your site is like assuming that because a person has seat belts in his car he can't get out and attack you. (The seat belt is there to protect the driver of the car, not you.) – apsillers Oct 1 '13 at 15:07

The purpose of the same-origin policy is to protect the user (client) and not you (the server). Thus, it's irrelevant in this case. Attackers can use tools like wget, cURL, and even simply inject custom JavaScript in modern browsers using readily-available tools such as Developer Tools.

Therefore, it doesn't matter if old browsers have certain behaviours or not, an attacker will probably not use a browser at all.

All rate-limiting rules and restrictions must be applied server-side.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.