0

I have an e-commerce website with a REST backend and a Single page JS as front end. I intend to secure my REST backend with OAuth2.

I don't want to oblige the user to authenticate when he first comes on the website, because as a e-commerce website, it is normal for the user to navigate to see the products, etc (maybe I am wrong...). So, on these 'public' pages, as I perform Ajax calls on by backend, is it worth to secure these URLs on my backend ? If not, what are the risks ?

Indeed, if I secure theses URLs on my backend, what can prevent any user to access these secured backend URLs by performing requests from the frontend ?

Maybe I am paranoid, but I think I should try to secure these URLs to prevent some attackers to use my backend for free or something else.

There would be no problem anymore for me if I oblige the user to authenticate. That's why I ask again if it is really the way to go for e-commerce...

Thank you very much.

|improve this question
1

Yes. You are responsible for ensuring that only authorized access is allowed to your REST interface. If the interface is meant to be accessed only from tje front end, you are responsible for ensuring that this is exactly what happens.

What are the risks? well, what functionality does your REST API offer? If an unauthorized cleint can connect, read data, and submit commands, then they can use your REST API to do whatever your REST API can do. They can delete whatever your API will let them delete, modify whatever your api lets them modify, read anything that it lets them read, and create new whatevers that your api lets them create. And i ftjere are other issues with your API implementation, like buffer overruns, then those will be exposed to the attacker, too.

|improve this answer
  • So, how can I secure these backend URLs in order to be only accessible by frontend, and ONLY if the user is navigating on the frontend ? How can I prevent the user to perform a request directly from the frontend without navigating on it (by a REST client for example, as soon as he knows the URL to attack) ? – rico Sep 23 '13 at 8:16
  • It depends upon exactly what you have control over. Ideally, there should be network controls restricting who can communicate with the back end, monitored audit logs of network traffic to detect inappropriate communications, authentication between the front end and the back end, authorization controls restricting different roles' access (unauthenticated access, authenticated user access, authenticated admin access, authenticated system level access) – atk Sep 23 '13 at 14:45
  • 'there should be network controls restricting who can communicate with the back end'. That is exactly what I want. How could I manage this ? – rico Sep 23 '13 at 14:55
  • First off, that's not the only thing that should be in place. Second, that depends upon your environment, budget, and ops team. It's not really something I can answer here. Instead, you should hire an expert. – atk Sep 23 '13 at 15:46
1

There is no effective way to secure your REST back-end so only your JavaScript front-end can access it. What you need to do instead is design your REST back-end based on the knowledge that a malicious user can access it directly.

This involves some technical controls, such as validating input server-side. It may also involve some business considerations. For example, the REST back-end will let a competitor "screen scrape" your site very effectively. Most e-commerce sites are happy with this risk, although some implement anti-scraping measures.

How exactly are you planning to use OAuth2? Do you make users register when they go to the checkout? I presume you will allow anyone on the internet to register for an account, so even the REST endpoints that are restricted to logged-in users need to be secured.

|improve this answer

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.