Common security guidance (applies to all Nextedy apps)

Modified on Sat, 11 Apr at 9:54 AM

Security responsibility model

Nextedy Polarion add-ons are deployed and executed entirely within the customer's Polarion environment. They do not introduce an independent authentication system or external network exposure. Add-on servlets operate within Polarion's web container and are accessible only through the authenticated Polarion session.
As a result, security responsibilities are shared between the Polarion platform and the add-ons, with clear boundaries.

Platform-level security (Polarion responsibility)

The following security aspects are provided and enforced by the Polarion platform and the customer's deployment configuration:

User authentication and authorization (roles, permissions, project access) [1]
Session management and identity context [1]
HTTPS / TLS termination and certificate management [2]
Content Security Policy (CSP) configuration at the HTTP(S) server level
CSRF protection mechanisms on state-changing operations [3]
Network exposure, firewalling, and perimeter security
Operating system, JVM, and database hardening [3]
Central logging and monitoring infrastructure
SQL injection prevention at the database access layer — including restricted SQL commands and project-level query filtering (since Polarion 2410) [4]
Secure secrets storage via User Account Vault [5]

Nextedy add-ons rely on these platform mechanisms and do not bypass or replace them.

Add-on-level security (Nextedy responsibility)

Within this environment, Nextedy add-ons are responsible for:

Correct and secure use of Polarion APIs
Respecting the authenticated user context provided by Polarion
Applying safe rendering patterns when presenting user-controlled data
Avoiding direct insertion of untrusted HTML or JavaScript into the DOM in regular user paths
Providing conservative default limits for queries and data processing
Clearly separating regular usage from privileged configuration capabilities

Privileged and scriptable functionality

Some Nextedy add-ons provide advanced configuration capabilities, including scriptable or programmable behavior, to support flexible customer-specific use cases.
Because such capabilities may execute custom logic and therefore carry increased security risk, access to scriptable or otherwise privileged configuration is intentionally restricted to trusted roles.
In this document, "administrator" refers to users with Project Administrator privileges or equivalent trusted roles.
This restriction follows Polarion's established security model and is enforced using one of the following patterns, depending on the add-on:

Restricted widgets (Polarion 2506+) — Certain widgets are classified as restricted and require the Pages.MODIFY RESTRICTED WIDGETS permission to configure. Regular users can use preconfigured widgets but cannot modify their configuration or inject scripts. Note: Restricted widget support requires Polarion 2506 or newer. On older Polarion versions, any user with the Pages.MODIFY permission can access widget configuration. Customers running older Polarion versions should restrict the Pages.MODIFY permission to trusted roles to achieve equivalent protection. [6]
Administrator-only configuration pages — Advanced configuration is available only through dedicated administration pages that are accessible exclusively to users with at least Project Administrator privileges. [7]

Customers are responsible for assigning appropriate roles and ensuring that only trusted administrators or power users are granted access to restricted or scriptable configuration capabilities.

Add-on customization is provided through three mechanisms, all protected by the role-based restrictions described above and accessible only to trusted roles:

Server-side JavaScript configuration — executes on the Polarion server with access to Polarion Open API, Polarion Rendering API, and Nextedy product APIs.
Client-side JavaScript configuration — executes in the browser with access to Nextedy product JavaScript APIs.
Server-side Velocity configuration — executes on the Polarion server with access to Polarion Open API, Polarion Rendering API, and Nextedy product APIs.

Add-ons do not attempt to sandbox or validate arbitrary custom scripts beyond this role-based restriction model.

Input handling and rendering safety

Nextedy add-ons provide various administrator-configurable rendering contexts — including custom cell renderers, top panel content, PDF cover pages, formula definitions, and other template-driven outputs. These are configured via Velocity templates, JavaScript expressions, or declarative configuration, and they control how work item data is processed and displayed. The security of these rendering paths depends on which Polarion API the administrator chooses to use.

Rendering API responsibility split

Polarion provides two primary methods for accessing work item data in these configurable contexts:

Rendering API (e.g., $workItem.title.render) — performs built-in HTML sanitization. Content rendered through this API is safe for display. Nextedy strongly recommends using the Rendering API in all administrator-configurable rendering contexts.
Open API / raw data access (e.g., $workItem.title via IWorkItem) — returns raw, unsanitized content. Data accessed through this path is not HTML-escaped by the platform.

If an administrator chooses to use raw Open API output in a custom render function, it is the administrator's responsibility to sanitize the output before display. Polarion provides escape utilities for this purpose: $esc.html($workItem.title) on LiveDocs and LiveReport Pages, or $esc.escape($esc.escapeForHtmlTag($workItem.title)) on Wiki Pages. [8]

Administrator responsibility for custom rendering

Custom render functions are exclusively configurable by administrators (Project Administrator role or higher). These paths:

May render output that includes HTML content without automatic escaping, depending on the API used
Require administrators to use the Rendering API or apply manual escaping when working with user-controlled data
Represent an accepted administrative risk when raw API output is used without sanitization

This is consistent with Polarion's own security model. Polarion's documentation warns that "poorly written code on Wiki Pages, Live Documents or LiveReport Pages can leave your system open to XSS attacks" and recommends restricting modification access to trusted users. [6]

Protection against XSS (Cross-Site Scripting)

XSS risks are mitigated through a layered approach:

Strict use of Polarion's secure Rendering API for regular user-facing data display
Administrator-only access to configuration paths that may render raw HTML
Controlled handling of user-generated content in regular (non-admin) user paths
Internal code review practices checking for unsafe DOM manipulation

Protection against CSRF (Cross-Site Request Forgery)

State-changing operations performed by Nextedy add-ons rely on Polarion's platform-level CSRF protection mechanisms. Add-ons operate within the security context enforced by the Polarion platform and do not bypass these protections. [3]

Content Security Policy (CSP)

CSP configuration is managed at the Polarion HTTP(S) server level. Nextedy components operate strictly within the CSP defined by the customer's Polarion deployment. No additional CSP relaxations are required for the operation of Nextedy add-ons.

Performance and operational security considerations

Certain add-on features may issue queries or process large data sets. While this functionality is required for advanced use cases, misconfiguration or excessive limits may impact system performance.
To mitigate operational risks:

Conservative default limits are applied where applicable.
Configuration options that increase load are restricted to privileged users.
Administrators are advised to carefully evaluate performance impact before increasing limits or applying changes in production environments.

Performance-related misconfiguration is considered an administrative risk and should be managed accordingly.

Logging and auditability

Nextedy add-ons rely on Polarion's logging and audit infrastructure and are aligned with Polarion's standard logging levels (Log4j). [9]
Security-relevant events such as authentication, authorization decisions, and configuration changes are logged at the platform level. Add-ons do not introduce separate security logging or monitoring subsystems.
At the transaction level, add-on activity is recorded by Polarion's transaction logger (TXLOGGER) within the standard Polarion log files. TXLOGGER entries include the authenticated username, request URL (including project ID, document path, and API endpoint), transaction performance data, and permission check details. Log entries do not contain credentials, work item content, or field values beyond identifiers.
Beyond TXLOGGER, Polarion's standard Log4j logging captures application-level events, errors, and diagnostic information at configurable severity levels. Nextedy add-ons use these same logging categories and levels — no custom logging framework is introduced.
Administrators should use existing Polarion logs and operational monitoring to detect misconfiguration or unusual behavior.

Dependency and supply chain risk management

Nextedy products are tested against Syft's vulnerability database for known dependency risks as part of the release process. A Software Bill of Materials (SBOM) in CycloneDX format is generated for each release and made available as part of the security package. This enables customers to independently verify third-party component risks and track known vulnerabilities (CVEs) in add-on dependencies.

Out of scope

The following areas are explicitly outside the scope of Nextedy add-ons and remain the responsibility of the Polarion deployment and customer operations:

Operating system and infrastructure security
Network perimeter protection and segmentation
Database encryption and backup protection
Centralized security monitoring (SIEM)
Disaster recovery and backup strategies

Product-specific considerations

Risksheet

The Risksheet add-on uses document-based configuration that is stored and managed within the Polarion platform.

Risksheet configuration is stored as document data (e.g., attachments and metadata) and is subject to Polarion's standard permission model.
Access to the Risksheet configuration editor in the UI is restricted to users with at least Project Administrator privileges.
Configuration is typically defined at the level of a template document, which is referenced by individual Risksheet instances.
Because configuration is stored as document data, administrators must ensure that permissions on template documents, attachments, and related metadata are appropriately restricted.
If regular users are granted edit access to template documents or configuration attachments, they may be able to change configuration indirectly using standard Polarion mechanisms.
The add-on applies configurable limits to the amount of data processed and rendered. Default limits are set conservatively.
Administrators can adjust limits as required; however, increasing these limits may impact Polarion performance and should be evaluated carefully.

Gantt

The Gantt add-on provides advanced visualization and planning capabilities that may process and render large data sets.

Gantt is implemented as a restricted widget, ensuring that configuration requires elevated permissions.
Regular users can use preconfigured views but cannot modify configuration or inject scripts.
The add-on applies configurable limits to the amount of data processed and rendered in a single view. Default limits are set conservatively.
Administrators can adjust limits as required; however, increasing these limits may significantly impact Polarion performance and should be evaluated carefully, preferably in non-production environments.

Powersheet

The Powersheet add-on uses centrally managed configuration stored in the Polarion repository.

Powersheet configuration is managed via administration interfaces intended for users with at least Project Administrator privileges.
Configuration is stored in the Polarion SVN repository (.polarion location). By default, Polarion permission schemes restrict write access to these repository locations to administrators; regular users do not have write access.
Configuration may include advanced or scriptable behavior and is therefore considered privileged.
Regular users can work with Powersheet data using configured views but cannot modify configuration or inject custom logic.

Planningboard

The Planningboard add-on follows the same security model as Gantt for advanced configuration.

Implemented as a restricted widget with elevated permissions required for configuration.
Regular users can use preconfigured views but cannot modify configuration or inject scripts.
Configurable limits are applied conservatively by default.

Checklist

The Checklist add-on renders structured content from Polarion fields as a visual checklist editor.

The add-on does not support scripting or execution of custom logic.
Checklist templates are defined at the level of template work items and subject to Polarion's standard permission model.
The add-on relies entirely on Polarion's platform-level security mechanisms.

Administrator checklist

When deploying and operating Nextedy Polarion add-ons, administrators should ensure that:

Access to restricted widgets and administrator-only configuration pages is limited to trusted roles (e.g., Project Administrators). In particular, the Pages.MODIFY RESTRICTED WIDGETS permission should be granted only to trusted users.
Template documents, configuration attachments, and repository-based configuration artifacts are write-protected for regular users using Polarion's standard mechanisms such as space-level permissions or custom permission sets.
Scriptable or advanced configuration is reviewed, approved, and maintained only by trusted administrators.
Default performance-related limits are preserved unless a change is explicitly required and its impact is carefully evaluated.
Configuration changes are tested in non-production environments where possible.
Polarion platform security features (authentication, authorization, HTTPS/TLS, permissions, and logging) remain enabled and correctly configured.
SQL and Lucene query restrictions introduced in Polarion 2410 remain at their default (restricted) settings. [4][7]

References

All references point to Polarion documentation. URLs are version-specific; update when targeting a different Polarion release.