Skip to main content

​
Architecture

Nextedy products (Risksheet, Powersheet, Gantt, Checklist, Planningboard) are deployed and executed entirely within the customer’s Polarion environment. They run in the same JVM process as Polarion itself, not as separate services, and they introduce no independent authentication system and no external network exposure. Each product registers its own endpoints within the Polarion server. These endpoints are:
  • Accessible only within the Polarion perimeter — Product endpoints are served by the same web container as Polarion itself. They are not exposed on separate ports or external URLs, and are reachable only through an authenticated Polarion session.
  • Protected by Polarion authentication — Every request to a product endpoint is authenticated through Polarion’s session management. Unauthenticated requests are rejected before reaching product code.
  • Subject to Polarion’s access control — Product endpoints enforce the same project-level and role-based permissions as the rest of Polarion.
Additional security properties:
  • No separate TLS configuration — Product endpoints inherit the server’s TLS settings.
  • No debug interfaces in production — Nextedy products do not include diagnostic endpoints, admin consoles, or debug ports in production builds.

​
Shared Responsibility Model

Because the products run inside Polarion, security responsibilities are shared between the platform and the add-ons, with clear boundaries. Provided and enforced by the Polarion platform (and by the customer’s deployment configuration):
  • User authentication and authorization — roles, permissions, project access
  • Session management and identity context
  • HTTPS/TLS termination and certificate management
  • Content Security Policy (CSP) configuration at the HTTP(S) server level
  • CSRF protection on state-changing operations
  • Network exposure, firewalling, and perimeter security
  • Operating system, JVM, and database hardening
  • 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)
  • Secure secrets storage through the User Account Vault
Nextedy products rely on these platform mechanisms and do not bypass or replace them. The responsibility of Nextedy products:
  • Correct and secure use of the 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

​
Authentication

Nextedy products delegate all authentication to the Polarion platform. They do not implement their own login mechanism and do not store or manage user credentials. Polarion supports the following authentication methods, all of which work transparently with Nextedy products: Nextedy products never see user passwords. They receive the authenticated user context from Polarion’s session management layer.

​
Authorization

Nextedy products read Polarion’s permission model at runtime to determine what the current user is allowed to see and do. The products cannot bypass or escalate Polarion permissions. Specifically:
  • Project access — If a user does not have access to a Polarion project, Nextedy products will not display data from that project.
  • Work item permissions — Read/write access to work items respects Polarion’s role-based permissions.
  • Field-level access — Custom field visibility and editability follow Polarion’s field configuration.
  • Document permissions — LiveDoc access is governed by Polarion’s document-level permissions.

​
Session Management

Nextedy products use Polarion’s session management. There are no separate sessions, tokens, or cookies introduced by the products. When a Polarion session expires or is invalidated, the product’s session ends automatically.

​
Privileged and Scriptable Configuration

Some Nextedy products 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.
Throughout this section, “administrator” means a user with Project Administrator privileges or an equivalent trusted role.
This restriction follows Polarion’s established security model and is enforced using one of two patterns, depending on the product:
  • Restricted widgets (Polarion 2506 and later) — 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.
  • Administrator-only configuration pages — Advanced configuration is available only through dedicated administration pages, accessible exclusively to users with at least Project Administrator privileges.
Restricted widget support requires Polarion 2506 or newer. On older Polarion versions, any user holding the Pages.MODIFY permission can access widget configuration. If you run an older Polarion version, restrict Pages.MODIFY to trusted roles to achieve equivalent protection.
Product customization is provided through three mechanisms, all protected by the role-based restrictions above: Nextedy products do not attempt to sandbox or validate arbitrary custom scripts beyond this role-based restriction model. Assigning appropriate roles — and ensuring that only trusted administrators or power users can reach restricted or scriptable configuration — is the customer’s responsibility.

​
Input Handling and Rendering Safety

Nextedy products provide administrator-configurable rendering contexts, including custom cell renderers, top panel content, PDF cover pages, formula definitions, and other template-driven output. These are configured through 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:
  • Rendering API (for example $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 (for example $workItem.title via IWorkItem) returns raw, unsanitized content that the platform does not HTML-escape.
If an administrator uses raw Open API output in a custom render function, sanitizing that output before display is the administrator’s responsibility. Polarion provides escape utilities for this purpose:
Custom render functions are configurable by administrators only. Where raw API output is used without sanitization, this represents an accepted administrative risk. This is consistent with Polarion’s own security model, whose documentation warns that poorly written code on Wiki Pages, LiveDocs, or LiveReport Pages can expose the system to XSS, and recommends restricting modification access to trusted users.

​
Protection Against Common Web Attacks

​
Query and Processing Limits

Some product features issue queries or process large data sets. While this is required for advanced use cases, misconfiguration or excessive limits may affect system performance. To mitigate operational risk:
  • Conservative default limits are applied where applicable.
  • Configuration options that increase load are restricted to privileged users.
  • Administrators should evaluate the performance impact before increasing limits or applying changes in production.
Performance-related misconfiguration is considered an administrative risk and should be managed accordingly.

​
Per-Product Considerations

Risksheet uses document-based configuration stored and managed within the Polarion platform.
  • Configuration is stored as document data (for example attachments and metadata) and is subject to Polarion’s standard permission model.
  • Access to the configuration editor in the UI is restricted to users with at least Project Administrator privileges.
  • Configuration is typically defined on a template document, which individual Risksheet instances reference.
  • 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 have edit access to template documents or configuration attachments, they may be able to change configuration indirectly through standard Polarion mechanisms.
  • Configurable limits are applied to the amount of data processed and rendered, with conservative defaults.
Powersheet uses centrally managed configuration stored in the Polarion repository.
  • Configuration is managed through administration interfaces intended for users with at least Project Administrator privileges.
  • Configuration is stored in the Polarion SVN repository (the .polarion location). By default, Polarion permission schemes restrict write access to these repository locations to administrators; regular users have no write access.
  • Configuration may include advanced or scriptable behavior and is therefore treated as privileged.
  • Regular users work with Powersheet data through configured views but cannot modify configuration or inject custom logic.
See also the Powersheet security architecture.
Gantt provides advanced visualization and planning that may process and render large data sets.
  • Gantt is implemented as a restricted widget, so configuration requires elevated permissions.
  • Regular users can use preconfigured views but cannot modify configuration or inject scripts.
  • Configurable limits are applied to the amount of data processed and rendered in a single view, with conservative defaults. Increasing these limits may significantly affect Polarion performance and should be evaluated carefully, preferably outside production.
Planningboard 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 renders structured content from Polarion fields as a visual checklist editor.
  • Checklist does not support scripting or execution of custom logic.
  • Checklist templates are defined on template work items and are subject to Polarion’s standard permission model.
  • The product relies entirely on Polarion’s platform-level security mechanisms.

​
Secure Development Practices

Nextedy applies the following practices to product development: All security findings are triaged before each release. Critical and high findings must be resolved before a release is approved. See Supply Chain Security for SBOM details.

​
Administrator Checklist

When deploying and operating Nextedy products, ensure that:
  • Access to restricted widgets and administrator-only configuration pages is limited to trusted roles. In particular, grant Pages.MODIFY RESTRICTED WIDGETS only to trusted users.
  • Template documents, configuration attachments, and repository-based configuration artifacts are write-protected for regular users, using Polarion 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 kept unless a change is explicitly required and its impact has been evaluated.
  • Configuration changes are tested outside production where possible.
  • Polarion platform security features — authentication, authorization, HTTPS/TLS, permissions, and logging — remain enabled and correctly configured.
  • The SQL and Lucene query restrictions introduced in Polarion 2410 remain at their default (restricted) settings.

​
Out of Scope

The following areas are outside the scope of Nextedy products 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
Last modified on August 20, 2026