Answers.Body: <p>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)</p>
  
  <p>So if it's client js, the authentication is done through the CMS, so via the cookie session. You shouldn't use the keys.</p>
  
  <p>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</p>
  
  <p>X+</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-17T22:46:00.760Z
Answers.Text: 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.
Answers.UserDisplayName: DaveFF
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-18T00:32:43.953Z
Answers.Text: 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?
Answers.UserDisplayName: Xavier
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-18T15:42:17.480Z
Answers.Text: 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.
Answers.UserDisplayName: DaveFF
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-17T20:08:43.560Z
Answers.LastActivityDate: 2015-09-17T20:08:43.560Z
Answers.UserDisplayName: Xavier
Body: <p><a href="https://www.owasp.org/index.php/REST_Security_Cheat_Sheet#Authentication_and_session_management" rel="nofollow">This OWASP document</a> 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.</p>
  
  <p>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).</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Is there any accepted best practice for treatment of CiviCRM REST API keys at the client side?</p>
  
Tags: <api><security><rest><cookies>
Title: Security of REST API keys
ThreadText: # Security of REST API keys
  
  (Asked by: username_0 on 2015-09-17)
  
  [This OWASP document](https://www.owasp.org/index.php/REST_Security_Cheat_Sheet#Authentication_and_session_management) 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?
  
  **Tags:** api, security, rest, cookies
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-09-17. Score: 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+
  
  > **Comments:**
  > **username_0**: 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.  
  > **username_1**: 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?  
  > **username_0**: 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.  
  
  ---
  
  