2

This OWASP document suggests that API keys for REST APIs should be passed as a POST parameter or a cookie. Not a GET parameter, because they can appear in the server logs.

Elsewhere they suggest that the right HTTP verb be used. Writes already have to be a POST request, so maybe read-only calls should still be a GET request (it makes the intent clearer).

As a GET or a POST parameter, the API key will still need to be accessible to client-side JS (assuming that's what your frontend app is written in). It may therefore be vulnerable to XSS.

A cookie can have the HttpOnly flag set so that on any modern browser it will not be accessible to client-side JS (and therefore safer against XSS). It will still be passed back to the server with each request. To set such a cookie, the frontend and backend probably need to be within the same domain.

In CRM_Utils_REST (as of 4.4 at least), the api_key is retrieved from $_REQUEST, which includes $_GET and $_POST. It used to include $_COOKIE (which would enable cookies to be used for the API key), but that is no longer the default in PHP due to other security concerns.

Is there any accepted best practice for treatment of CiviCRM REST API keys at the client side?

Improve this question

1 Answer 1

Reset to default
2

To clarify, they are two ways of accessing the api over the net, the REST interface (that uses the keys) and the ajax one (that is used for the front end js, and doesn't need the keys)

So if it's client js, the authentication is done through the CMS, so via the cookie session. You shouldn't use the keys.

What we recommend is to always use POST when we use the REST, not matter the action, precisely to avoid having the keys in the GET params, so it's not left in the logs and a bit more protected in general

X+

Improve this answer
3
  • Our new portal for members has been developed outside of Civi using a JS framework. They have expected to be able to communicate with Civi using only the REST API. We've got ways of making it work, but I'm trying to treat the keys as securely as reasonably possible.
    – DaveFF
    Commented Sep 17, 2015 at 22:46
  • but are you expecting to communicate directly from the browser of the member to civi using the rest api or is this always channelled through your js framework as an intermediate server?
    – Xavier
    Commented Sep 18, 2015 at 0:32
  • The JS that will communicate with the REST API is in the client's browser. There is no intermediate server. The JS app will most likely be served from a different directory on the same host.
    – DaveFF
    Commented Sep 18, 2015 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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