1

Assume that you have a web application. The backend API is deployed at api.example.com and your frontend SPA is deployed at frontend.example.com. When you open it you download all the resources to your browser. The origin is frontend.example.com, yet when you are sending requests to the backend they are actually sent to api.example.com which is not the same origin.

So an SPA naturally breaks the same-origin policy since in most cases the API it works against is not the origin it stands on. So my question is, is there a way to develop a SPA without breaking the same-origin policy, and without using some tricky tech like CORS or JSONP?

| improve this question | |
2

If you want to avoid making cross origin requests, host your frontend and your API on the same origin. If you host them on different origins, by definition you must make cross origin requests.

And if you do have to make cross origin requests, just use CORS. JSONP is an ugly hack that should be avoided. It was used back in the day in situations like this, because there was no CORS back then. Then CORS was developed to deal exactly with the kind of situation you describe.

So asking how to make cross origin requests without CORS is sort of like asking how to hit a nail without a hammer. Just use the hammer, that's what it's there for!

| improve this answer | |
0

If you break the same origin policy your app would not function at all. Browsers are very strict about this, they will not let you break this rule.

I wrote a short post on the same origin policy. It will help put the whole idea in perspective.

So my question is, is there a way to develop a SPA without breaking the same-origin policy, and without using some tricky tech like CORS or JSONP?

Of course! If you serve the initial page of your SPA from the domain you host your backend on, you do not need CORS or JSONP to communicate with your backend at all.

| improve this answer | |
  • Hi, thank you for your answer. But I give an example here. Assume that you have a web application, the backend API is deployed at api.example.com and your frontend SPA is deployed at frontend.example.com. And once you opened it you downloaded all the resources to your browser. And indeed the origin is frontend.example.com, yet when you sending the request to the backend is actually sent to api.example.com which is not the same origin. So the point is SPA naturally breaks the same-origin policy since most cases the API it against to is not the origin it stands on. – Qingbao Aug 30 '17 at 9:39
  • @Qingbao, if you define an SPA as you did, you are perfectly right. When you deploy the frontend on a different domain from the backend, you need CORS to talk to it. There is no way around it. And there shouldn't be! CORS was designed exactly for this purpose. What makes you skeptical about CORS? – Daniel Szpisjak Aug 30 '17 at 12:39
  • I'm not skeptical about CORS actually. A new project lets me rethink a SPA in terms of "security" when having so many APIs to be shared. And just curious if someone has the same thought. :) – Qingbao Aug 31 '17 at 13:12
  • 1
    @Qingbao, think about it this way. The same origin policy prevents Apps on different domains to communicate by default. SPAs, due to their nature, are often deployed on a separate domain from the backend they will be calling (they do not have to be though). In this case, you must let the browser know that the SPA is "part of a larger app which also has a backend". The standard way of doing this is CORS. It is no trick, it is the perfect solution for the given problem. Using a good policy won't make your app any less secure. – Daniel Szpisjak Aug 31 '17 at 15:33

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.