Answers.Body: <p>According to the <a href="http://wiki.civicrm.org/confluence/display/CRMDOC/API+Security" rel="nofollow">API Security page</a>, this is expected behaviour - only the Contact API applies ACLs and such.</p>
  
  <p>Looks like the best solution is to <a href="http://wiki.civicrm.org/confluence/display/CRMDOC/How+to+migrate+or+write+an+api" rel="nofollow">write a custom API</a> that limits available data.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-12T03:35:52.143Z
Answers.Text: Yes, I agree with this analysis. In 4.7 there are some underying changes in the api that lay the ground work for applying ACLs to addresses & other tables (& this could be backported to 4.6) but the extra step of adding the ACLs has not yet been done 
  
  (note that if you would prefer to fund that work in core than write a custom api you can go through the paid issue queue - https://civicrm.org/paid-issue-queue - this would obviously benefit others if you did)
Answers.UserDisplayName: eileen
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-12T11:44:20.463Z
Answers.LastActivityDate: 2015-08-12T11:44:20.463Z
Answers.UserDisplayName: Andrew West
Body: <p>To get contact data via the API you only need the 'access CiviCRM' permission, as long as you have access to the contact in question somehow (via an ACL or whatever). But to get address data for the same contact you need the 'view all contacts' permission. Is there a reason address data is more locked down? Can I override it?</p>
  
  <p>Our use case is: a third-party website is accessing Civi via the REST API. This website is managed by a third-party, so I don't want to use an API key that gives them full database access. So I've set up a user who only has access to the relevant contacts. I can get the basic contact data fine, but I can't get their addresses without altering this global api permission requirement.</p>
  
  <p>I'm just a bit nervous about changing this in case it's going to open any security holes elsewhere...</p>
  
  <p>Here's the code in question, in CRM/Core/DAO/permissions.php :</p>
  
  <pre><code>  // Contact permissions
    $permissions['contact'] = array(
      'create' =&gt; array(
        'access CiviCRM',
        'add contacts',
      ),
      'delete' =&gt; array(
        'access CiviCRM',
        'delete contacts',
      ),
      // managed by query object
      'get' =&gt; array(),
      'update' =&gt; array(
        'access CiviCRM',
        'edit all contacts',
      ),
      'getquick' =&gt; array(
        array('access CiviCRM', 'access AJAX API'),
      ),
    );
  
    // Contact-related data permissions.
    // CRM-14094 - Users can edit and delete contact-related objects using inline edit with 'edit all contacts' permission
    $permissions['address'] = array(
      'get' =&gt; array(
        'access CiviCRM',
        'view all contacts',
      ),
      'default' =&gt; array(
        'access CiviCRM',
        'edit all contacts',
      ),
    );
  </code></pre>
  
  <p>Emails, phone numbers, websites, instant messaging etc. all use the same 'view all contacts' requirement.</p>
  
Tags: <api><permissions>
Title: Should accessing addresses via the API always require the 'view all contacts' permission?
ThreadText: # Should accessing addresses via the API always require the 'view all contacts' permission?
  
  (Asked by: username_0 on 2015-08-11)
  
  To get contact data via the API you only need the 'access CiviCRM' permission, as long as you have access to the contact in question somehow (via an ACL or whatever). But to get address data for the same contact you need the 'view all contacts' permission. Is there a reason address data is more locked down? Can I override it?
  
  Our use case is: a third-party website is accessing Civi via the REST API. This website is managed by a third-party, so I don't want to use an API key that gives them full database access. So I've set up a user who only has access to the relevant contacts. I can get the basic contact data fine, but I can't get their addresses without altering this global api permission requirement.
  
  I'm just a bit nervous about changing this in case it's going to open any security holes elsewhere...
  
  Here's the code in question, in CRM/Core/DAO/permissions.php :
  
  ```
    // Contact permissions
    $permissions['contact'] = array(
      'create' => array(
        'access CiviCRM',
        'add contacts',
      ),
      'delete' => array(
        'access CiviCRM',
        'delete contacts',
      ),
      // managed by query object
      'get' => array(),
      'update' => array(
        'access CiviCRM',
        'edit all contacts',
      ),
      'getquick' => array(
        array('access CiviCRM', 'access AJAX API'),
      ),
    );
  
    // Contact-related data permissions.
    // CRM-14094 - Users can edit and delete contact-related objects using inline edit with 'edit all contacts' permission
    $permissions['address'] = array(
      'get' => array(
        'access CiviCRM',
        'view all contacts',
      ),
      'default' => array(
        'access CiviCRM',
        'edit all contacts',
      ),
    );
  
  ```
  
  Emails, phone numbers, websites, instant messaging etc. all use the same 'view all contacts' requirement.
  
  **Tags:** api, permissions
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2015-08-12. Score: 1 | Accepted answer
  
  According to the [API Security page](http://wiki.civicrm.org/confluence/display/CRMDOC/API+Security), this is expected behaviour - only the Contact API applies ACLs and such.
  
  Looks like the best solution is to [write a custom API](http://wiki.civicrm.org/confluence/display/CRMDOC/How+to+migrate+or+write+an+api) that limits available data.
  
  > **Comments:**
  > **username_1**: Yes, I agree with this analysis. In 4.7 there are some underying changes in the api that lay the ground work for applying ACLs to addresses & other tables (& this could be backported to 4.6) but the extra step of adding the ACLs has not yet been done   (note that if you would prefer to fund that work in core than write a custom api you can go through the paid issue queue - https://civicrm.org/paid-issue-queue - this would obviously benefit others if you did)  
  
  ---
  
  