Disable plone.protect for all API calls

[sneridagh]

There is a way to disable it always for all restapi calls? Or it is required to disable it manually always?

        # Disable CSRF protection
        if 'IDisableCSRFProtection' in dir(plone.protect.interfaces):
            alsoProvides(self.request,
                         plone.protect.interfaces.IDisableCSRFProtection)

If so, maybe we can provide a convenience decorator for that...

@tisto @lukasgraf @buchi any insights?

[lukasgraf]

@sneridagh can you give a specific example of which REST API service causes this problem? An existing one or a new one you're trying to implement?

I feel disabling it completely for plone.restapi requests might be a security issue, at least in cases where a user is authenticated with basic auth and has an existing webbrowser-session.

[sneridagh]

@lukasgraf The existing ones have to disable it on write requests, I just wonder if there was a discussion about the subject at some point. It's true that may be a security issue, but we are already disabling it when the operation require a write request, otherwise plone.protect does not allow to do the write operation.

Regarding the case that you mentioned, if it would be done through JS, CORS wouldn't be able to prevent it from happening?

[tisto]

@vangheem do you have an opinion on that matter? ^^^

[vangheem]

What we decided is as long as these requests can not be created with normal web url/form posts, then it's fine to completely drop CSRF protection.

From what I remember, the only way the endpoints match and are used is if the Content-Type header is provided with application/json. AFAIK, there is no way to spoof that without javascript running on the client making the request. So in that scenario, it is fine to drop CSRF protection because those views would not be vulnerable.

You'll want to double check that this is true though.

[raphael-ritz]

Just want to mention that the AutoUserMakerPASPlugin had a similar problem and solved it by declaring the intended changes within a safe_write context. See collective/Products.AutoUserMakerPASPlugin@a20e182 for the concrete implementation in that case.

Not sure this makes sense to be considered in the situation here. Just want to mention this anyway. Maybe someone more knowledgeable than me can provide an opinion?