Export (0) Print
Expand All

Privacy and security for apps for Office

apps for Office

This article provides an overview of the security model for apps for Office in general, and provides links to resources for additional information about specific app types and implementations.

Last modified: March 03, 2015

Applies to: Access apps for SharePoint | apps for Office | Excel | Outlook | PowerPoint | Project | Word

Learn more about supported hosts and other requirements.

In this article
Understanding the app runtime
App integrity in the Office Store
Addressing end users’ privacy concerns
Developers’ permission choices and security practices
IT administrators’ control
Additional resources

Apps for Office are secured by an app runtime environment, a multiple-tier permissions model, and performance governors. This framework protects the user's experience in the following ways:

  • Access to the host application's UI frame is managed.

  • Only indirect access to the host application's UI thread is allowed.

  • Modal interactions aren't allowed – for example, calls to JavaScript alert, confirm, and prompt functions aren't allowed because they're modal.

Further, the runtime framework provides the following benefits to ensure that an app for Office can't damage the user's environment:

  • Isolates the process the app runs in.

  • Doesn't require .dll or .exe replacement or ActiveX components.

  • Makes apps easy to install and uninstall.

Also, the use of memory, CPU, and network resources by apps for Office is governable to ensure that good performance and reliability are maintained.

The following sections briefly describe how the runtime architecture supports running apps in Office clients on Windows-based devices, on OS X Mac devices, and in Office Online clients on the web.

Clients for Windows, Windows RT, and OS X devices

In supported clients for desktop and tablet devices, such as Excel, Excel RT, Outlook, Outlook for Mac, and Outlook RT, apps for Office are supported by integrating an in-process component, the apps for Office runtime, which manages the app lifecycle and enables interoperability between the app and the client application. The app webpage itself is hosted out-of-process. As shown in figure 1, on a Windows or Windows RT desktop or tablet device, the app webpage is hosted inside an Internet Explorer control which, in turn, is hosted inside an app runtime process that provides security and performance isolation.

Figure 1. Apps for Office runtime environment in Windows-based desktop and tablet clients

Rich-client infrastructure

As shown in figure 2, on an OS X Mac desktop, the app web page is hosted inside a sandboxed WebKit runtime host process which helps provide similar level of security and performance protection.

Figure 2. Apps for Office runtime environment in OS X Mac clients

Apps for Office runtime environment on OS X Mac

The apps for Office runtime manages interprocess communication, the translation of JavaScript API calls and events into native ones, as well as UI remoting support to enable the app to be rendered inside the document, in a task pane, or adjacent to an email message, meeting request, or appointment.

Web clients

In supported Web clients, such as Excel Online and Outlook Web App, apps for Office are hosted in an iframe that runs using the HTML5 sandbox attribute. ActiveX components or navigating the main page of the web client are not allowed. Apps for Office support is enabled in the web clients by the integration of the JavaScript API for Office. In a similar way to the desktop client applications, the JavaScript API manages the app lifecycle and interoperability between the app and the web client. This interoperability is implemented by using a special cross-frame post message communication infrastructure. The same JavaScript library (Office.js) that is used on desktop clients is available to interact with the web client. Figure 3 illustrates the infrastructure that supports apps for Office in the Office Online (running in the browser), and the relevant components (the web client, iframe, apps for Office runtime, and JavaScript API for Office) that are required to support them.

Figure 3. Infrastructure that supports apps for Office in Office web clients

Web-client infrastructure

You can make your apps for Office available to the public by publishing them in the Office Store. The Office Store enforces the following measures to maintain the integrity of apps:

  • Requires the host server of an app for Office to always use Secure Sockets Layer (SSL) to communicate.

  • Requires a developer to provide proof of identity, a contractual agreement, and a compliant privacy policy to submit apps.

  • Ensures that the source of apps is accessible in read-only mode.

  • Supports a user-review system for available apps to promote a self-policing community.

This section addresses end users’ privacy concerns when using apps for Office. First, it describes the protection offered by the apps for Office platform from the customer's (end user's) perspective. Then, it provides you as the developer with guidelines about how to support users' expectations and how to securely handle users’ personally identifiable information (PII).

End users’ perspective

Apps for Office are built using web technologies that run in a browser control or iframe. Because of this, using apps is similar to browsing to web sites on the Internet or intranet. Apps can be external to an organization (if you acquire the app from the Office Store) or internal (if you acquire the app from an Exchange Server app catalog, SharePoint app catalog, or file share on an organization's network). Apps have limited access to the network and most apps can read or write to the active document or mail item. The app platform applies certain constraints before a user or administrator installs or starts an app. But as with any extensibility model, users should be cautious before starting an unknown app.

The app platform addresses end users’ privacy concerns in the following ways:

  • Data communicated with the web server that hosts a content, mail or task pane app as well as communication between the app and any web services it uses must be encrypted using the Secure Socket Layer (SSL) protocol.

  • Before a user installs an app from the Office Store, the user can view the privacy policy and requirements of that app. In addition, mail apps that interact with users’ mailboxes surface the specific permissions 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 or associated with 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 organizational environment, the Office 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, users manage access to trusted apps and catalogs from the Trust Center on the host Office client (opened from File > Options > Trust Center > Trust Center Settings > Trusted App Catalogs). For mail apps, uses can manage apps by choosing the Manage Apps button: in Outlook for Windows or Outlook RT, choose File > Manage Apps. In Outlook for Mac, choose the Manage Apps button on the app bar. In Outlook Web App choose the Settings menu (gear icon) > Manage apps. Administrators can also manage this access by using group policy.

  • The design of the app platform provides security and performance for end users in the following ways:

    • An app for Office runs in a web browser control that is hosted in an app runtime environment separate from the Office host application. This design provides both 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 but, at the same time, restricts the app to observe the same-origin policy for domain isolation and security zones.

Icon for mail apps for Office

Mail apps provide additional security and performance features through mail app-specific resource usage monitoring. For more information, see Privacy, permissions and security for mail apps in Outlook.

Developer guidelines to handle PII

You can read general PII protection guidelines for IT administrators and developers in Protecting Privacy in the Development and Testing of Human Resources Applications. The following lists some specific PII protection guidelines for you as a developer of apps for Office:

  • The Settings object is intended for persisting app settings and state data across sessions for a content or task pane app, but don't store passwords and other sensitive PII in the Settings object. The data in the Settings object isn't visible to end users, but it is stored as part of the document’s file format which is readily accessible. You should limit your app's use of PII and store any PII required by your app on the server hosting your app as a user-secured resource.

  • Using some applications can reveal PII. Make sure that you securely store data for your users’ identity, location, access times, and any other credentials so that data won't 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 the same level of protection.

  • If you store users’ PII, make sure you reveal that fact, and provide a way for users to inspect and delete it. If you submit your app to the Office Store, you can outline the data you collect and how it's used in the privacy statement.

Follow these general guidelines to support the security model of apps for Office, and drill down on more details for each app type.

Permissions choices

The app platform provides a permissions model that your app uses to declare the level of access to a user's data that it requires for its features. Each permission level corresponds to the subset of the JavaScript API for Office your app is allowed to use for its features. For example, the WriteDocument permission for content and task pane apps allows access to the Document.setSelectedDataAsync method that lets an app write to the user's document, but doesn't allow access to any of the methods for reading data from the document. This permission level makes sense for apps that only need to write to a document, such as an app where the user can query for data to insert into his or her document.

As a best practice, you should request permissions based on the principle of least privilege. That is, you should request permission to access only the minimum subset of the API that your app requires to function correctly. For example, if your app needs only to read data in a user's document for its features, you should request no more than the ReadDocument permission. (But, keep in mind that requesting insufficient permissions will result in the app platform blocking your app's use of some APIs and will generate errors at run time.)

You specify permissions in the manifest of your app, as shown in the example in this section below, and end users can see the requested permission level of an app before they decide to install or activate the app for the first time. Additionally, mail apps that request the ReadWriteMailbox permission require explicit administrator privilege to install.

The following example shows how a task pane app specifies the ReadDocument permission in its manifest. To keep permissions as the focus, other elements in the manifest aren't displayed.

<?xml version="1.0" encoding="utf-8"?>
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.0"
…<!-- To keep permissions as the focus, not displaying other elements. -->

Icon for mail apps for Office

For more information about requesting permission levels for mail apps, see the following topics:

Same origin policy

Because apps for Office are webpages that run in a web browser control, they must follow the same-origin policy enforced by the browser: by default, a webpage in one domain can't 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 another domain. You 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 Sample: Create a mail app to view YouTube videos in Outlook.

// 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.

Exchange and SharePoint provide client-side proxies to enable cross-domain access. In general, same origin policy on an intranet isn't 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.

Tips to prevent malicious cross-site scripting

An ill-intentioned user could attack the origin of an app by entering malicious script through the document or fields in the app. A developer should process user input 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:

    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 doesn't 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.

Tips to prevent "Clickjacking"

Because apps for Office are rendered in an iframe when running in a browser with Office Online host applications, use the following tips to minimize the risk of clickjacking—a technique used by hackers to fool users into revealing confidential information.

First, identify sensitive actions that your app can perform. These include any actions that an unauthorized user could use with malicious intent, such as initiating a financial transaction or publishing sensitive data. For example, your app might let the user send a payment to a user-defined recipient.

Second, for sensitive actions, your app should confirm with the user before it executes the action. This confirmation should detail what effect the action will have. It should also detail how the user can prevent the action, if necessary, whether by choosing a specific button marked "Don’t Allow" or by ignoring the confirmation.

Third, to ensure that no potential attacker can hide or mask the confirmation, you should display it outside the context of the app (that is, not in an HTML dialog box).

Here are some examples of how you could get confirmation:

  • Send an email to the user that contains a confirmation link.

  • Send a text message to the user that includes a confirmation code that the user can enter in the app.

  • Open a new browser window that contains a confirmation prompt.

Also, ensure that the address you use for contacting the user couldn't have been provided by a potential attacker. For example, for payment confirmations use the address on file for the authorized user's account.

Other security practices

Developers should also take note of the following security practices:

  • Developers shouldn't use ActiveX controls in apps for Office as ActiveX controls don't 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 only by 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 aren't delivering content by 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 isn't 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 don't 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 shouldn't embed keys that they use to access third-party APIs or services (such as Bing, Google, or Facebook) directly in the HTML pages of their app. Instead, they should create a custom web service or store the keys in some other form of secure web storage that they can then call to pass the key value to their app.

  • 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.

Icon for mail apps for Office

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 JavaScript API for mail apps in Outlook.

In a corporate setting, IT administrators have ultimate authority over enabling or disabling access to the Office Store and any private catalogs. For more information, see Overriding resource usage settings for performance of apps for Office.

© 2015 Microsoft