Privacy and security for apps for Office

This section addresses end users’ privacy concerns from the end users’ perspective. Apps for Office are built using web technologies. Using apps is analogous to browsing to web sites on the Internet or intranet. Apps can be external (if the app is acquired from the Office Store) or internal (if the app is acquired from a SharePoint app catalog or file share on a network). As such, apps have access to the network and most apps read or write to the active document or mail item. The app platform applies a series of controls before a user or administrator installs or starts an app. But as with any extensibility model, the user should be cautious before starting an unknown app.

The extensibility platform for apps for Office addresses end users’ privacy concerns in the following ways:

• Data communicated with a web server that hosts a mail app, and communication between a content or task pane app and a web service are always encrypted according to the Secure Socket Layer (SSL) protocol.

• Before a user installs an app from the Office Store, the user can view the privacy policy of that app. In addition, mail apps that interact with users’ mailboxes surface the specific permission that they require; the user can review the terms of use, requested permissions and privacy policy before installing a mail app.

• When sharing a document, users also share apps that have been inserted in that document. If a user opens a document that contains an app that the user hasn't used before, the host application prompts the user to grant permission for the app to run in the document. In an organization environment, the host application also prompts the user if the document comes from an external source.

• Users can enable or disable the access to the Office Store. For content and task pane apps, this access is built into the trusted apps and catalogs accessible from the Trust Center on the host rich client. For mail apps, this access is via the Backstage view of the Outlook rich client. Administrators can also manage this access by using group policy.

• To avoid accidentally installing apps from the Internet, users take explicit steps of setting up the Insert menu and enabling external catalogs in the Internet zone before installing any apps for Office from the catalog.

• The intrinsic architecture design of apps for Office provides assurance for end users:

  • An app for Office runs in a web browser control, in an app runtime environment separate from the Office host application. This design provides mutual security and performance isolation from the host application.

  • Running in a web browser control allows the app to do almost anything a regular web page running in a browser can do and, at the same time, restricts the app to observe the same-origin policy for domain isolation and security zones.

End users of mail apps enjoy additional security and performance assurance as a result of mail app-specific resource usage monitoring. For more information, see Privacy and security for mail apps in Outlook.

There are some general guidelines for IT administrators and developers to protect PII in Protecting Privacy in the Development and Testing of Human Resources Applications. The following lists some specific guidelines when developing apps for Office:

• Even though the Settings object is intended for persisting document-specific data for a content or task pane app, do not store PII in the Settings object. The data in the Settings object is not visible to end users, but is part of the document’s file format which is readily accessible. You should store PII on your server as a user-secured resource.

• Usage of some applications can reveal PII. Make sure that you securely store data for your users’ identity, location, access times, and any other credentials such that the data will not become available to other users of the app.

• If your app is available in the Office Store, the Office Store requirement for HTTPS protects PII transmitted between your web server and the client computer or device. However, if you re-transmit that data to other servers, make sure you observe that same level of protection.

• If you store users’ PII, make sure you reveal that so that users have a choice to inspect and delete it. If you submit your app to the Office Store, you can outline the data you collect and its usage in the privacy statement.

Permission is the mechanism for an app to request access to functionality in the JavaScript API for Office. A developer should request the minimum necessary permission that offers access to the set of API that an app uses, keeping in mind that the more permission that’s requested, the smaller the set of users who will make use of the app. Requesting insufficient permission, on the other hand, can result in the host application blocking the use of specific APIs in the app and generating errors at run time.

Developers request permissions in the manifest for an app, as shown in the example in this section below, and end users can see the requested permission of an app before they decide to install or start the app for the first time. In particular, mail apps that request the Read/write mailbox permission require explicit administrator privilege to install.

The following example shows how a task pane app requests ReadDocument permission in its manifest. To keep permissions as the focus, other elements in the manifest are not displayed.

<?xml version="1.0" encoding="utf-8"?>
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:ver="http://schemas.microsoft.com/office/appforoffice/1.0"
xsi:type="TaskPaneApp">
…<!-- To keep permissions as the focus, not displaying other elements. -->
  <Permissions>ReadDocument</Permissions>
…
</OfficeApp>

For more information about requesting permission levels for task pane apps, see Requesting permissions by task pane apps.

For more information about requesting permission levels for content apps, see Requesting permissions by content apps.

For more information about requesting permission levels for mail apps, see the following topics: Privacy and security for mail apps in Outlook Using the permission model for mail apps in Outlook

Because apps for Office are webpages that run in a web browser control, they have to observe the same-origin policy: a webpage in one domain cannot make XmlHttpRequest web service calls to another domain other than the one where it is hosted.

One way to overcome this limitation is to use JSON/P—provide a proxy for the web service by including a script tag with a src attribute that points to some script hosted on any domain. The developer can programmatically create the script tags, dynamically creating the URL to which to point the src attribute, and passing parameters to the URL via URI query parameters. Web service providers create and host JavaScript code at specific URLs, and return different scripts depending on the URI query parameters. These scripts then execute where they are inserted and work as expected.

The following is an example of JSON/P in the mail app example How to: Build a mail app for Outlook to view YouTube videos.

// Dynamically create an HTML SCRIPT element that obtains the details for the specified video.
function loadVideoDetails(videoIndex) {
    // Dynamically create a new HTML SCRIPT element in the webpage.
    var script = document.createElement("script");
    // Specify the URL to retrieve the indicated video from a feed of a current list of videos,
    // as the value of the src attribute of the SCRIPT element. 
    script.setAttribute("src", "https://gdata.youtube.com/feeds/api/videos/" + 
        videos[videoIndex].Id + "?alt=json-in-script&callback=videoDetailsLoaded");
    // Insert the SCRIPT element at the end of the HEAD section.
    document.getElementsByTagName('head')[0].appendChild(script);
}

Exchange and SharePoint provide client-side proxies to enable cross-domain access. In general, same origin policy on an intranet is not as strict as on the Internet. For more information, see Same Origin Policy Part 1: No Peeking and Addressing same-origin policy limitations in apps for Office.

An ill-intentioned user could attack the origin of an app by inputting malicious HTML through the document or fields in the app. A developer should appropriately process user inputs to avoid executing a malicious user's JavaScript within his or her domain. The following are some good practices to follow to handle user input from a document or mail message, or via fields in an app:

• Instead of the DOM property innerHTML, use the innerText and textContent properties where appropriate. Do the following for Internet Explorer and Firefox cross-browser support:

  JavaScript

  Copy

  var text = x.innerText || x.textContent
  

  For information about the differences between innerText and textContent, see Node.textContent. For more information about DOM compatibility across common browsers, see W3C DOM Compatibility - HTML.

• If you must use innerHTML, make sure the user’s input does not contain malicious content before passing it to innerHTML. For more information and an example of how to use innerHTML safely, see innerHTML property.

• If you are using jQuery, use the .text() method instead of the .html() method.

• Use the toStaticHTML method to remove any dynamic HTML elements and attributes in users’ input before passing it to innerHTML.

• Use the encodeURIComponent or encodeURI function to encode text that is intended to be a URL that comes from or contains user input.

• See Developing secure apps for more best practices to create more secure web solutions.

Developers should also take note of the following security practices:

• Developers should not use ActiveX controls in apps for Office as ActiveX controls do not support the cross-platform nature of the app platform.

• Content and task pane apps assume the same SSL settings that Internet Explorer uses by default, and allows most content to be delivered by only SSL. Mail apps require all content to be delivered by SSL. Developers must specify in the SourceLocation element of the app manifest a URL that uses HTTPS, to identify the location of the HTML file for the app.

  To make sure apps are not delivering content using HTTP, when testing apps, developers should make sure the following settings are selected in Internet Explorer and no security warnings appear in their test scenarios:

  • Make sure the security setting, Display mixed content, for the Internet zone is set to Prompt. You can do that by selecting the following in Internet Explorer: on the Security tab of the Internet Options dialog box, select the Internet zone, select Custom level, scroll to look for Display mixed content, and select Prompt if it is not already selected.

  • Make sure Warn if Changing between Secure and not secure mode is selected in the Advanced tab of the Internet Options dialog box.

• To make sure that apps do not use excessive CPU core or memory resources and cause any denial of service on a client computer, the app platform establishes resource usage limits. As part of testing, developers should verify whether an app performs within the resource usage limits. For more information, see Following resource usage rules in apps for Office.

• Before publishing an app, developers should make sure that any personal identifiable information that they expose in their app files is secure.

• Developers should do the following when submitting an app to the Office Store:

  • Host the app they are submitting on a web server that supports SSL.

  • Produce a statement outlining a compliant privacy policy.

  • Be ready to sign a contractual agreement upon submitting the app.

Other than resource usage rules, developers for mail apps should also make sure their apps observe limits for specifying activation rules and using the JavaScript API. For more information, see Limits for activation and data in mail apps for Outlook.