WebAPI/Security/Contacts: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
Ptheriault (talk | contribs) No edit summary |
||
Line 1: | Line 1: | ||
== Contacts API == | |||
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 | ||
References: | |||
*https://wiki.mozilla.org/WebAPI/ContactsAPI | |||
*https://groups.google.com/d/topic/mozilla.dev.webapps/hvG5PXsFyzw/discussion | |||
=== 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 | ||
|- | |||
| Installed Web Apps || None || No access (access via web activities)|| | |||
*App requests a contact via web activities or trusted UI | |||
*API provides a local identifier instead of the actual contact information | |||
|- | |||
| Privileged Web Apps || Create, read or edit contact information || Explicit || | |||
* 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 Web Apps || Create, read or edit contact information || Implicit || | |||
|} | |||
__NOTOC__ | __NOTOC__ |
Revision as of 12:32, 24 September 2012
Contacts API
Brief purpose of API: Access to users contacts.
General Use Cases:N/A
Inherent threats:
- Read/exfiltrate confidential information,
- Destroy user's contact data
- DoS via filling address book with bogus data
Threat severity: High
References:
- https://wiki.mozilla.org/WebAPI/ContactsAPI
- https://groups.google.com/d/topic/mozilla.dev.webapps/hvG5PXsFyzw/discussion
Permissions Table
Type | Use Cases | Authorization Model | Notes & Other Controls |
---|---|---|---|
Web Content | None | No direct access (access via web activities) |
|
Installed Web Apps | None | No access (access via web activities) |
|
Privileged Web Apps | Create, read or edit contact information | Explicit |
|
Certified Web Apps | Create, read or edit contact information | Implicit |