WebAPI/Security/Contacts: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 1: Line 1:
Name of API: [[WebAPI/ContactsAPI|Contacts API]]
== Contacts API ==
 
References:
*https://wiki.mozilla.org/WebAPI/ContactsAPI
*https://groups.google.com/d/topic/mozilla.dev.webapps/hvG5PXsFyzw/discussion
 
Brief purpose of API: Access to users contacts.
Brief purpose of API: Access to users contacts.


Line 16: Line 11:
Threat severity: High
Threat severity: High


== Regular web content (unauthenticated) ==
References:
Use cases for unauthenticated code: Mediated access to specific (user selected) contact
*https://wiki.mozilla.org/WebAPI/ContactsAPI
information
*https://groups.google.com/d/topic/mozilla.dev.webapps/hvG5PXsFyzw/discussion


Authorization model for uninstalled web content: Explicit via web activities


Authorization model for installed web content: Explicit via web activities


Potential mitigations:
=== Permissions Table===
 
{| border="1" class="wikitable"
! Type
! Use Cases
! Authorization Model
! Notes & Other Controls
|-
| Web Content || None || No direct access (access via web activities)||
*App requests a contact via web activities or trusted UI
*App requests a contact via web activities or trusted UI
*API provides a local identifier instead of the actual contact information
*API provides a local identifier instead of the actual contact information
 
|-
== Privileged (approved by app store) ==
| Installed Web Apps || None || No access (access via web activities)||
Use cases for privileged code: Create, read or edit contact information
*App requests a contact via web activities or trusted UI
 
*API provides a local identifier instead of the actual contact information
Authorization model: Explicit
|-
 
| Privileged Web Apps || Create, read or edit contact information || Explicit ||
Potential mitigations:
* Let user configure what data is accessible (globally?)
* Let user configure what data is accessible (globally?)
* Have separate permissions for read vs read&write, assuming that many apps only want read, and could use web activities to create a contact if necessary.  These distinctions should not be exposed to the user (the user should be only be asked if the API wants to "have access to" the contacts API, as it adds too much cognitive overhead to start scanning dialogs for the verb without clearly differentiating the risk to the user).
* Have separate permissions for read vs read&write, assuming that many apps only want read, and could use web activities to create a contact if necessary.  These distinctions should not be exposed to the user (the user should be only be asked if the API wants to "have access to" the contacts API, as it adds too much cognitive overhead to start scanning dialogs for the verb without clearly differentiating the risk to the user).
 
|-
== Certified (system-critical apps) ==
| Certified Web Apps || Create, read or edit contact information || Implicit ||
Use cases for certified code: Create, read or edit contact information
|}
 
Authorization model: Implicit
 
Potential mitigations: None


__NOTOC__
__NOTOC__
canmove, Confirmed users
1,220

edits