Best way to restrict web services?

At the beginning of your API, at the same place where you checks your arguments you can check your $api->user object to apply your restrictions.

By exemple the ConfigModuleApi check if you are admin or developer for one module when you try to save a config for a module.

I have some clever users calling the built-in APIs which are the same that Sugar Uses for the UI.

like "Contacts/" to query/update/add contacts

If they can query/enter/update records via the UI they can do it via a webservices API.

It would be nice to just be able to have a webservices ACL per user or per module so I can lock out any chosen user from all or specific modules via webservices.

More importantly I should be able to stop certain users from creating/updating records via web services.

We have some clever people here...

FrancescaS

You can't use role or custom Sugar ACL for that ?

If you want to deal about API only you can check on a before_api_call logic hook and then manage a security layer at this place may be

The Role ACL would limit what they can do via the UI, not just the API. There are people that I want to be able to Read and Write via UI but not via API. 

I guess the problem is distinguishing between an API call made from within the Application and an API call made from somewhere else...

I will check the before_api_call to see what I can do there. Thanks.

FrancescaS

Hey Francesca Shiekh,

In theory if the UI and the API are already aligned on what they allow/not allow a user to do, it should not matter how the users interact with the system, as the UI is just the presentation layer that facilitates the interaction with the API.

Is there a specific reason why you are concerned of users accessing the API directly? As long as custom APIs are all built respecting the ACL and visibility (or other additional restrictions you might have on your system) I am not sure it matters that much.

In any case given that in Sugar the UI is just the mean to interact with the API (same as the mobile app or the plugins) I am not sure what you could do to prevent users from leveraging it directly.

If you see it from the user's perspective, it would be good to investigate what the users are trying to do, that make them want (or need) to use the API directly instead of the UI, and see if you could facilitate their actions through a custom UI?

Cheers

I started to write my reply and the more I think about it the more I feel like I'm just a control freak.

The main reason I started this thread is that the UI has dependencies, required fields, duplicate checks, javascript triggers alerts and checks and balances that cannot be avoided in the UI but need to be explicitly addressed in the API.

A series of API calls can also easily be added to a cron job and cause load issues which are much more easily controlled through the UI.

If I can control who has access to the API I can make sure that the user is well educated on the potential pitfalls of API usage. It is easier to control who gets in, than to track which API did what. If the API is adding Sugar records I have a trail of who added them and can ask questions, but if the system gets overloaded with queries tracking who is making those queries gets a little more challenging. Sure, I can check the access log, track the machine they originated from, check with all the users who have access to that machine... it's not a simple lookup.

Maybe I'm overthinking this...

FrancescaS

I think it's a characteristic of modern web applications that the same APIs that a client browser uses can be exploited programmatically by somebody else using them for different purposes. It's certainly a big security challenge.

There's things you can try - like filtering on HTTP headers like User Agent, but I'm sure your users are savvy enough to work around simple restrictions like that.

I think your best option is forensics. Monitor the logs. Maybe even implement rate limits on things like the Filter API.