Menu
-->
![Microsoft Microsoft](/uploads/1/3/3/2/133276012/807097731.png)
![Microsoft Word Addins Greyed Out Mac Microsoft Word Addins Greyed Out Mac](/uploads/1/3/3/2/133276012/915934854.png)
- Microsoft Word Options Greyed Out
- Microsoft Word 2007 Add Ins
- Word Dictate Greyed Out
- Microsoft Word Addins Greyed Out Mac Pro
- Word Toolbar Greyed Out
Office add-ins help you personalize your documents and streamline the way you access information on the web (see Start using your Office Add-in). As an admin, you can deploy Office add-ins for the users in your organization. You can do this using the Centralized Deployment feature in the Microsoft 365 admin center.
- Apr 05, 2018 Microsoft Office add-ins let you do this—and much more—without switching programs. When you want a bit more from Office, these add-ins each make Microsoft Word, Excel, PowerPoint, and Outlook more powerful with new features for free. Best of all, they work in the free Office Online apps as well as newer versions of Office for Mac and Windows.
- Apr 17, 2018 For PowerPoint 2003 and for Word 2003. Start PowerPoint 2003, or Word 2003. On the Tools menu, point to Macro, and then click Security. On the Trusted Publishers tab, click to select the Trust all installed add-ins and templates check box, and then click OK. For PowerPoint 2002 and for Word 2002. Start PowerPoint 2002 or Word 2002.
Centralized Deployment is the recommended and most feature-rich way for most admins to deploy add-ins to users and groups within an organization. For more information on how to determine if your organization can support Centralized Deployment, see Determine if Centralized Deployment of add-ins works for your Office 365 organization.
Centralized Deployment provides the following benefits:
Hi, I have upgraded to X8.2 (13302) and I then upgraded word for mac 16.9 (180116) The CWYW tab does not appear in the toolbar. I went to tools/templates and addins and the endnote cwyw is listed but greyed out.
- A Global admin can assign an add-in directly to a user, to multiple users via a group, or to everyone in the tenant.
- When the relevant Office application starts, the add-in automatically downloads for the user. If the add-in supports add-in commands, the add-in automatically appears in the Ribbon within the Office application.
- Add-ins will no longer appear for users if the admin turns off or deletes the add-in, or if the user is removed from Azure Active Directory or from a group that the add-in is assigned to.
Note
For Word, Excel and PowerPoint use a SharePoint App Catalog to deploy add-ins to users in an on-premises environment with no connection to Office 365 and/or support for SharePoint add-ins required. > For Outlook use Exchange control panel to deploy in an on-premises environment without a connection to Office 365. >
Recommended approach for deploying Office add-ins
Consider rolling out add-ins in a phased approach to help ensure your add-in deployment goes smoothly. We recommend the following plan:
- Roll-out the add-in to a small set of business stakeholders and members of the IT department. Evaluate if the deployment was successful, and if so, move on to step 2.
- Roll-out to a larger set of individuals within the business who will be using the add-in. Again, evaluate results and, if all went well, go to the next step of a full deployment.
- Full rollout to target audience of users.
Depending on the size of the target audience, you may want to add or remove roll-out steps.
Deploy an Office add-in using the admin center
Before you begin, see Determine if Centralized Deployment of add-ins works for your Office 365 organization.
- In the Microsoft 365 admin center, go to the Settings > Add-ins page.
- Select Deploy Add-in at the top of the page. On the overview page, select Next.
- Select an option and follow the instructions.
- If you selected the option to add an add-in from the Office Store, you can now make your add-in selection. Notice that you can view available add-ins via categories of Suggested for you, Rating, or Name. Only free add-ins are available to add from the Office Store. Paid add-ins aren't supported currently. Once you've selected your add-in, you will need to agree to some additional terms and conditions in order to proceed.
NOTE: With the Office Store option, updates and enhancements to the add-in will automatically be made available to users without your intervention. - Microsoft remote desktop mac 8 vs 10. On the next page, select Everyone, Specific users/groups or Just me to specify who the add-in is deployed to. Use the Search box to find the users or groups who you want to deploy the add-in to.
NOTE: Learn about the other states that apply to an add-in. See Add-in states later in this topic. - Select Deploy.
- A green tick will appear when the add-in has been deployed. You can follow the on-page instructions to test that the add-in has deployed successfully.
Note
Users may need to relaunch Office to see the add-in icon appear on the ribbon of app. Outlook add-ins can take up to 24 hours to appear on users' ribbons.
- When finished, select Next. If you've deployed to just yourself, you can select Change who has access to add-in in order to deploy to more users.
If you've deployed the add-in to members of your organization other than yourself, follow the instructions displayed in order to effectively announce the deployment of the add-in.
You now see your add-in along with other apps in Office 365.
You now see your add-in along with other apps in Office 365.
It's a good idea to inform the users and groups who you deployed the add-in to so that they know that it's available. Consider sending an email to them that describes when and how to use the add-in and explains how the add-in can help them do their job better. Include or link to relevant Help content or FAQs that might help if users have any problems with the add-in.
Considerations when assigning an add-in to users and groups
Admins can assign an add-in to everyone or to specific users and groups. Each option has implications:
- Everyone: As the name implies, this option assigns the add-in to every user in the tenant. Use this option sparingly and only for add-ins that are truly universal to your organization.
- Users: If you assign an add-in to an individual user, then to deploy the add-in to a new user, you will need to first add that user. The same goes for removing users.
- Groups: If you assign an add-in to a group, users who are added to the group will automatically be assigned the add-in. And, when a user is removed from a group, the user loses access to the add-in. In either case, no additional action is required from you as the admin.
- Just me: If you assign an add-in to just yourself, this assigns the add-in to only your account. This is ideal if you wish to test out the add-in first.
The option that is right for your organization depends on your configuration. However, we recommend making assignments via groups. As an admin, you might find it easier to manage add-ins using groups and control the membership of those groups rather than having to change the users assigned each time. On the other hand, in some situations, you may want to restrict access to a very small set of users and therefore make assignments to specific users. As a result, you will need to manage the assigned users manually.
Add-in states
Admins can turn on or off the add-ins they deploy for all users from the Microsoft 365 admin center.
- In the admin center, go to the Settings > Add-ins page.
- Select the deployed add-in.
- Click the Status toggle to turn the add-in On or Off.
- Save the changes.
One of three add-in states is also available.
State | How the state occurs | Impact |
---|---|---|
Active | Admin uploaded the add-in and assigned it to users or groups. | Users and groups assigned to the add-in see it in the relevant clients. |
Turned off | Admin turned off the add-in. | Users and groups assigned to the add-in no longer have access to it. If the add-in state is changed to Active, the users and groups will have access to it again. |
Deleted | Admin deleted the add-in. | Users and groups assigned the add-in no longer have access to it. |
Consider deleting an add-in if no one is using it any more. Turning off an add-in may make sense if an add-in is used only during specific times of the year.
Microsoft Word Options Greyed Out
Security of Office add-ins
Office add-ins combine an XML manifest file that contains some metadata about the add-in, but most importantly points to a web application which contains all the code and logic. Add-ins can range in their capabilities. For example, add-ins can:
- Display data.
- Read a user's document to provide contextual services.
- Read and write data to and from a user's document to provide value to that user.
For more information about the types and capabilities of Office add-ins, see Office Add-ins platform overview, especially the section 'Anatomy of an Office Add-in.'
To interact with the user's document, the add-in needs to declare what permission it needs in the manifest. A five-level JavaScript API access-permissions model provides the basis for privacy and security for users of task pane add-ins. The majority of the add-ins in the Office Store are level ReadWriteDocument with almost all add-ins supporting at least the ReadDocument level. For more information about the permission levels, see Requesting permissions for API use in content and task pane add-ins.
When updating a manifest, the typical changes are to an add-in's icon and text. Occasionally, add-in commands change. However, the permissions of the add-in do not change. The web application where all the code and logic for the add-in runs can change at any time, which is the nature of web applications.
Updates for add-ins happen as follows: https://suprenew681.weebly.com/microsoft-outlook-export-to-mac-mail.html.
- Line-of-business add-in: In this case, where an admin explicitly uploaded a manifest, the add-in requires that the admin upload a new manifest file to support metadata changes. The next time the relevant Office applications start, the add-in will update. The web application can change at any time.NoteAdmin does not need to remove a LOB Add-in for doing an update. In the Add-ins section, Admin can simply click on the LOB Add-in and choose the Update Button in the bottom right corner. Update will work only if the version of the new add-in is greater than that of the existing add-in.
- Office Store add-in: When an admin selected an add-in from the Office Store, if an add-in updates in the Office Store, the add-in will update later in Centralized Deployment. The next time the relevant Office applications start, the add-in will update. The web application can change at any time.
Edit Add-in access
Post deployment, admins can also modify the user access to add-ins.
- In the admin center, go to the Settings > Services & add-ins page.
- Select the deployed add-in.
- Microsoft powerpoint 2013 free download for mac. Click on Edit under Who has Access.
- Save the changes.
Prevent add-in downloads by turning off the Office Store across all clients (Except Outlook)
Note
![Microsoft Microsoft](/uploads/1/3/3/2/133276012/807097731.png)
Outlook add-in installation is managed by a different process.
As an organization you may wish to prevent the download of new Office add-ins from the Office Store. This can be used in conjunction with Centralized Deployment to ensure that only organization-approved add-ins are deployed to users within your organization.
To turn off add-in acquisition:
- In the admin center, go to the Settings > Services & add-ins page.
- Select User owned apps and services.
- Clear the option to let users access the Office store.
This will prevent all users from acquiring the following add-ins from the store.
- Add-ins for Word, Excel, and PowerPoint 2016 from:
- Windows
- Mac
- Office
- Acquisitions starting within AppSource
- Add-ins within Office 365
A user who tries to access the store will see the following message: Sorry, Office 365 has been configured to prevent individual acquisition of Office Store add-ins.
Support for turning off the Office Store is available in the following versions:
- Windows: 16.0.9001 - Currently available.
- Mac: 16.10.18011401 - Currently available.
- iOS: 2.9.18010804 - Currently available.
- The web - Currently available.
This does not prevent an administrator from using Centralized Deployment to assign an add-in from the Office Store.
To prevent a user from signing in with a Microsoft account, you can restrict logon to use only the organizational account. For more information, look here.
Minors and acquiring add-ins from the Store
Microsoft Word 2007 Add Ins
The General Data Protection Regulation (GDPR) is a European Union regulation that becomes effective May 25, 2018. It gives users rights to and protection of their data. One of the aspects of the GDPR is that minors cannot have their personal data sent to parties that their parent or guardian hasn't approved. The specific age defined as a minor depends on the region where the individual is located.
Regions that have statutory regulations about parental consent include the United States, South Korea, the United Kingdom, and the European Union. For those regions, a minor will be blocked (via Azure Active Directory) from getting any new Office add-ins from the Store and running add-ins that were previously acquired. For countries without statutory regulations, there will be no download restrictions.
A user is determined to be a minor based on data specified in Azure Active Directory. The tenant admin is responsible for declaring the legal age group and the parental consent for that user.
If the parent/guardian consents to a minor using a specific add-In, then the tenant admin can use centralized deployment to deploy that add-In to all minors who have consent.
To be GDPR compliant for minors you need to ensure that one of following builds of Office is deployed in your school/organization.
For Word, Excel, PowerPoint, and Project:
Platform | Build number |
Office 2016 ProPlus Monthly for Windows | 9001.2138 |
Office 2016 ProPlus Semi-Annual | 8431.2159 |
Office 2016 for Windows | 16.0.4672.1000 |
Office 2013 for Windows | 15.0.5023.1000 |
Office 2016 for Mac | 16.11.18020200 |
Office for the web | N/A |
For Outlook:
Platform | Build number |
Outlook 2016 for Windows (MSI) | Build No TBD |
Outlook 2016 for Windows (C2R) | 16.0.9323.1000 |
Office 2016 for Mac | 16.0.9318.1000 |
Outlook mobile for iOS | 2.75.0 |
Outlook mobile for Android | 2.2.145 |
Outlook.com | N/A |
Office 2013 requirements
Word, Excel, and PowerPoint 2013 for Windows will support the same minor checks if Active Directory Authentication Library (ADAL) is enabled. There are two options for compliance, as explained next.
- Enable ADAL. This article explains how to enable ADAL for Office 2013: Using Office 365 modern authentication with Office clients.
You also need to set the registry keys to enable ADAL as explained in Enable Modern Authentication for Office 2013 on Windows devices.
Additionally, you need to install the following April updates for Office 2013: - Don't enable ADAL. If you're unable to enable ADAL in Office 2013, then our recommendation is to use Group Policy to turn off the Store for the office clients. Information on how to turn off the app for Office settings is located here.
![Microsoft Word Addins Greyed Out Mac Microsoft Word Addins Greyed Out Mac](/uploads/1/3/3/2/133276012/915934854.png)
End user experience with add-ins
Now that you've deployed the add-in, your end users can start using it in their Office applications (see Start using your Office Add-in). The add-in will appear on all platforms that the add-in supports.
If the add-in supports add-in commands, the commands appear on the Office ribbon. In the following example, the command Search Citation appears for the Citations add-in.
If the deployed add-in doesn't support add-in commands or if you want to view all deployed add-ins, you can view them via My Add-ins.
In Word 2016, Excel 2016, or PowerPoint 2016
- Select Insert > My Add-ins.
- Select the Admin Managed tab in the Office Add-ins window.
- Double-click the add-in you deployed earlier (in this example, Citations ).
In Outlook
- On the Home ribbon, select Get Add-ins.
- Select Admin-managed in the left nav.
Delete the add-in
You can also delete an add-in that was deployed.
- In the admin center, go to the Settings > Services & add-ins page.
- Select the deployed add-in.
- Click on Delete Add-In. Remove the Add-in button on the bottom right corner.
- Validate your selections, and choose Remove add-in.
Learn more
Learn more about creating and building Office Add-ins.
Use Centralized Deployment PowerShell cmdlets to manage add-ins.
-->Understanding the add-in runtime
Office Add-ins are secured by an add-in 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
, andprompt
functions aren't allowed because they're modal.
Further, the runtime framework provides the following benefits to ensure that an Office Add-in can't damage the user's environment:
- Isolates the process the add-in runs in.
- Doesn't require .dll or .exe replacement or ActiveX components.
- Makes add-ins easy to install and uninstall.
Also, the use of memory, CPU, and network resources by Office Add-ins is governable to ensure that good performance and reliability are maintained.
The following sections briefly describe how the runtime architecture supports running add-ins in Office clients on Windows-based devices, on OS X Mac devices, and in web browsers.
Clients on Windows and OS X devices
In supported clients for desktop and tablet devices, such as Excel on Windows, and Outlook on Windows and Mac, Office Add-ins are supported by integrating an in-process component, the Office Add-ins runtime, which manages the add-in lifecycle and enables interoperability between the add-in and the client application. The add-in webpage itself is hosted out-of-process. As shown in figure 1, on a Windows desktop or tablet device, the add-in webpage is hosted inside an Internet Explorer or Microsoft Edge control which, in turn, is hosted inside an add-in runtime process that provides security and performance isolation.
On Windows desktops, Protected Mode in Internet Explorer must be enabled for the Restricted Site Zone. This is typically enabled by default. If it is disabled, an error will occur when you try to launch an add-in.
Figure 1. Office Add-ins runtime environment in Windows-based desktop and tablet clients
As shown in the following figure, on an OS X Mac desktop, the add-in web page is hosted inside a sandboxed WebKit runtime host process which helps provide similar level of security and performance protection.
Figure 2. Office Add-ins runtime environment in OS X Mac clients
The Office Add-ins runtime manages interprocess communication, the translation of JavaScript API calls and events into native ones, as well as UI remoting support to enable the add-in to be rendered inside the document, in a task pane, or adjacent to an email message, meeting request, or appointment.
Web clients
Word Dictate Greyed Out
In supported Web clients, Office Add-ins 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. Office Add-ins 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 add-in lifecycle and interoperability between the add-in 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. The following figure shows the infrastructure that supports add-ins in Office running in the browser, and the relevant components (the web client, iframe, Office Add-ins runtime, and JavaScript API for Office) that are required to support them.
Figure 3. Infrastructure that supports Office Add-ins in Office web clients
Add-in integrity in AppSource
You can make your Office Add-ins available to the public by publishing them to AppSource. AppSource enforces the following measures to maintain the integrity of add-ins:
- Requires the host server of an Office Add-in 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 add-ins.
- Ensures that the source of add-ins is accessible in read-only mode.
- Supports a user-review system for available add-ins to promote a self-policing community.
Addressing end users' privacy concerns
This section describes the protection offered by the Office Add-ins platform from the customer's (end user's) perspective, and provides guidelines for how to support users' expectations and how to securely handle users' personally identifiable information (PII).
End users' perspective
Office Add-ins are built using web technologies that run in a browser control or iframe. Because of this, using add-ins is similar to browsing to web sites on the Internet or intranet. Add-ins can be external to an organization (if you acquire the add-in from AppSource) or internal (if you acquire the add-in from an Exchange Server add-in catalog, SharePoint app catalog, or file share on an organization's network). Add-ins have limited access to the network and most add-ins can read or write to the active document or mail item. The add-in platform applies certain constraints before a user or administrator installs or starts an add-in. But as with any extensibility model, users should be cautious before starting an unknown add-in.
The add-in platform addresses end users' privacy concerns in the following ways:
- Data communicated with the web server that hosts a content, Outlook or task pane add-in as well as communication between the add-in and any web services it uses must be encrypted using the Secure Socket Layer (SSL) protocol.
- Before a user installs an add-in from AppSource, the user can view the privacy policy and requirements of that add-in. In addition, Outlook add-ins 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 an Outlook add-in.
- When sharing a document, users also share add-ins that have been inserted in or associated with that document. If a user opens a document that contains an add-in that the user hasn't used before, the host application prompts the user to grant permission for the add-in 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 AppSource. For content and task pane add-ins, users manage access to trusted add-ins and catalogs from the Trust Center on the host Office client (opened from File > Options > Trust Center > Trust Center Settings > Trusted Add-in Catalogs). For Outlook add-ins, uses can manage add-ins by choosing the Manage Add-ins button: in Outlook on Windows, choose File > Manage Add-ins. In Outlook on Mac, choose the Manage Add-ins button on the add-in bar. In Outlook on the web, choose the Settings menu (gear icon) > Manage add-ins. Administrators can also manage this access by using group policy.
- The design of the add-in platform provides security and performance for end users in the following ways:
- An Office Add-in runs in a web browser control that is hosted in an add-in 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 add-in to do almost anything a regular web page running in a browser can do but, at the same time, restricts the add-in to observe the same-origin policy for domain isolation and security zones.
Outlook add-ins provide additional security and performance features through Outlook add-in specific resource usage monitoring. For more information, see Privacy, permissions, and security for Outlook add-ins.
Developer guidelines to handle PII
The following lists some specific PII protection guidelines for you as a developer of Office Add-ins:
- The Settings object is intended for persisting add-in settings and state data across sessions for a content or task pane add-in, 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 add-in's use of PII and store any PII required by your add-in on the server hosting your add-in 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 add-in.
- If your add-in is available in AppSource, the AppSource 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 add-in to AppSource, you can outline the data you collect and how it's used in the privacy statement.
Developers' permission choices and security practices
Follow these general guidelines to support the security model of Office Add-ins, and drill down on more details for each add-in type.
Permissions choices
The add-in platform provides a permissions model that your add-in 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 add-in is allowed to use for its features. For example, the WriteDocument permission for content and task pane add-ins allows access to the Document.setSelectedDataAsync method that lets an add-in 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 add-ins that only need to write to a document, such as an add-in where the user can query for data to insert into their 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 add-in requires to function correctly. For example, if your add-in 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 add-in platform blocking your add-in's use of some APIs and will generate errors at run time.)
You specify permissions in the manifest of your add-in, as shown in the example in this section below, and end users can see the requested permission level of an add-in before they decide to install or activate the add-in for the first time. Additionally, Outlook add-ins that request the ReadWriteMailbox permission require explicit administrator privilege to install.
The following example shows how a task pane add-in specifies the ReadDocument permission in its manifest. To keep permissions as the focus, other elements in the manifest aren't displayed.
For more information about permissions for task pane and content add-ins, see Requesting permissions for API use in add-ins.
For more information about permissions for Outlook add-ins, see the following topics:
Same origin policy
Because Office Add-ins 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 Outlook add-in example.
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 Office Add-ins.
Tips to prevent malicious cross-site scripting
An ill-intentioned user could attack the origin of an add-in by entering malicious script through the document or fields in the add-in. A developer should process user input to avoid executing a malicious user's JavaScript within their domain. The following are some good practices to follow to handle user input from a document or mail message, or via fields in an add-in:
- 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: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 add-ins for more best practices to create more secure web solutions.
Tips to prevent 'Clickjacking'
Because Office Add-ins are rendered in an iframe when running in a browser with Office 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 add-in 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 add-in might let the user send a payment to a user-defined recipient.
Second, for sensitive actions, your add-in 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.
Microsoft Word Addins Greyed Out Mac Pro
Third, to ensure that no potential attacker can hide or mask the confirmation, you should display it outside the context of the add-in (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 add-in.
- Open a confirmation dialog in a new browser window to a page that cannot be iframed. This is typically the pattern that is used by login pages. Use the dialog api to create a new dialog.
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:
Word Toolbar Greyed Out
- Developers shouldn't use ActiveX controls in Office Add-ins as ActiveX controls don't support the cross-platform nature of the add-in platform.
- Content and task pane add-ins assume the same SSL settings that the browser uses by default, and allows most content to be delivered only by SSL. Outlook add-ins require all content to be delivered by SSL. Developers must specify in the SourceLocation element of the add-in manifest a URL that uses HTTPS, to identify the location of the HTML file for the add-in.To make sure add-ins aren't delivering content by using HTTP, when testing add-ins, developers should make sure the following settings are selected in Internet Options in Control Panel 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 Options: on the Security tab, 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 add-ins don't use excessive CPU core or memory resources and cause any denial of service on a client computer, the add-in platform establishes resource usage limits. As part of testing, developers should verify whether an add-in performs within the resource usage limits.
- Before publishing an add-in, developers should make sure that any personal identifiable information that they expose in their add-in 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 add-in. 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 add-in.
- Developers should do the following when submitting an add-in to AppSource:
- Host the add-in 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 add-in.
Other than resource usage rules, developers for Outlook add-ins should also make sure their add-ins observe limits for specifying activation rules and using the JavaScript API. For more information, see Limits for activation and JavaScript API for Outlook add-ins.
IT administrators' control
In a corporate setting, IT administrators have ultimate authority over enabling or disabling access to AppSource and any private catalogs.
The management and enforcement of Office settings is done with group policy settings. These are configurable through the Office Deployment Tool, in conjunction with the Office Customization Tool.
Setting name | Description |
---|---|
Allow Unsecure web add-ins and Catalogs | Allows users to run non-secure add-ins, which are add-ins that have webpage or catalog locations that are not SSL-secured (https://) and are not in users' Internet zones. |
Block Web Add-ins | Allows you to prevent users from using web add-ins. |
Block the Office Store | Allows you to prevent users from using or inserting web add-ins that come from the Office Store. |
Important
If your working groups are using multiple releases of Office, group policy settings must be configured for each release. Please refer to the Using Group Policy to manage how users can install and use apps for Office of the Overview of apps for Office 2013 article for details on group policy settings for Office 2013.