Security considerations

When designing plugins, it is important to fully consider any potential security risks you may introduce to your tenant:

  • Your plugins will pass data to your tenant to be used in a workflow either directly (in Nintex Workflow), or via a SharePoint list (in Nintex Workflow for Office 365).

    • Ensure proper data sanitization and safety-checks are in place.

  • Plugins in your tenant can be added to a form design by any user with:
    • A Designer, Developer, or Administrator role in Nintex Workflow
    • Sufficient SharePoint permissions in Nintex Workflow for Office 365.

    • Do not assume form designers will only use your plugin as you intended.

  • Form plugins grant plugin developers significant control over your tenant. Follow the principle of least privilege and:
    • Assign the Developer role or SharePoint permissions only to a limited set of trusted users.
    • Allow only those same users to update hosted plugin files.

It is the plugin developer's responsibility to ensure their plugins adhere to best coding and security practices.

Cross-site scripting (XSS) attacks

To provide the Form plugins functionality, your Nintex Workflow or Nintex Workflow for Office 365 tenant must allow the execution of JavaScript provided by plugin developers. Allowing the execution of JavaScript in this manner can create a vulnerability to cross-site scripting attacks.

A cross-site scripting attack is when JavaScript from one domain is used to interfere with the behavior of another domain. Some examples include:

  • Redirecting users submitting forms to a malicious domain.
  • Key-logging or other data exfiltration when a user completes a form.
  • Modifying submitted or not-yet-submitted form data.
  • Spoofing and phishing attacks.
  • Changing the form's layout to hide, move, include, or modify controls.

Cross-site scripting attacks may come from several sources:

  • Hosting providers for externally hosted plugins may be vulnerable to attack, or may maliciously alter hosted plugin code to facilitate an attack.
  • Third-party JavaScript libraries used in your plugins may have vulnerabilities to cross-site scripting attacks.
  • Plugin developers may, unwittingly or otherwise, leave vulnerabilities in their plugin code.
  • Tenant users or anonymous end-users may exploit discovered vulnerabilities when submitting forms.

It is important to be aware of potential avenues of attack and adhere to rigorous coding and security standards. We recommend the following mitigation strategies as a minimum:

  • For externally hosted plugins or assets:
    • Choose hosting providers with a known track record who have sufficient RBAC controls in place.
    • Configure your hosting solution to send an alert when hosted files are changed.
  • Always use the latest version of third-party libraries.
  • Monitor third-party libraries for any newly-discovered vulnerabilities.
  • In Nintex Workflow, restrict the Developer role and access to the hosted plugin files to a limited set of trusted users.
  • Ensure all plugin code is reviewed by another developer.
  • Scan plugins with a static analysis security tool before registering them.
  • Use a JavaScript framework which is resistant to cross-site scripting attacks, such as Lit.
  • Never inject HTML directly with dynamic data.

See Resources and Best practices for more information.