Security Practices

Customer Portal Toolkit is designed as a Forge-hosted Jira Service Management Cloud app with trusted context, backend re-authorization, installation-scoped storage and privacy-treated disclosure.

Platform architecture

The App uses Jira Cloud, Jira Service Management APIs, Forge functions, Custom Entity Store, KVS, scheduled/async services, platform logging/metrics and optional Forge LLM. The manifest declares no remote, external fetch domain, third-party app analytics or End-User Data egress. Runs on Atlassian eligibility is a platform architecture signal, not a certification or guarantee against application defects.

Authentication, trusted context and authorization

• Atlassian authenticates users and invokes Forge modules.
• Installation, environment, actor/account class, project, request, module/location and license context are derived from trusted Forge/Jira context rather than frontend payload authority claims.
• Every sensitive read, configuration change, publication and customer action repeats the relevant backend authorization.
• Current-request reads and customer mutations prefer the current user and current Jira/JSM permission model.
• Reviewed app-principal aggregate paths accept only compiled, bounded, project-scoped plans and can return only privacy-treated presentations.
• Permission or capability failure is handled as a safe unavailable state; the App does not use app authority to impersonate a customer mutation.

Anonymous and unlicensed access

Anonymous or generic unlicensed output is restricted to explicitly public configuration-backed content on the supported portal header. This path has no request lookup, aggregate query, action, personalization, preference storage or AI. Customer request panels and actions require the supported authenticated JSM customer context and the relevant published policy.

Configuration and query safety

Configuration is runtime-schema validated, versioned and bounded. Administrators cannot supply arbitrary JavaScript, HTML, CSS, endpoints, methods, headers, payloads, JQL concatenation, templates or expressions. Conditions, transforms, field mappings, links and queries use typed values, allowlists and depth/size/cost limits. Aggregate queries remain project-bound and use enforced minimum cohort, generalization, freshness and differencing controls.

Customer actions

Actions use a closed allowlist and the current user's Jira/JSM permission and workflow. Immediately before mutation, the backend re-resolves the published widget and policy, validates the operation and bounded input, and applies confirmation, rate limits, atomic idempotency/replay protection and content-free pseudonymized audit. A stale preview is not authority to perform an action.

Storage and data protection

Durable configuration and records use Forge Custom Entity Store; short-lived cache, lease, budget, rate and idempotency state uses Forge KVS. Forge scopes hosted data per installation. Atlassian documents encryption and durability for hosted storage and provides data residency for eligible persistent Forge storage. Mederak Apps does not hold separate database credentials, customer API tokens or a copy of the App database.

Frontend and input safety

• Strict TypeScript and runtime schemas cover resolver inputs, stored records, upstream Jira responses and client outputs.
• React renders plain values; supported rich content and links use controlled projections and restricted URL protocols.
• No customer or tenant data is retained in module-level mutable state.
• Configuration size, pagination, functions, jobs and payloads are bounded.
• Partial failures are isolated so one unavailable widget does not disclose data or break sibling widgets.

Logging and monitoring

Application logs use safe codes, coarse operation metadata and correlation identifiers. They are designed not to include request/customer content, field values, comments, attachments, credentials, tokens, account emails, private Jira response bodies or full AI prompts/completions. Content-free audit records record selected configuration and action events for 180 days. Platform infrastructure logs remain controlled by Atlassian.

Scopes

Optional AI

Forge LLM is disabled by default at installation and widget level. Inputs are minimized to data already authorized for the current actor. Private comments, attachments, credentials and cross-customer request data are prohibited from the AI path. Output is bounded, schema/content validated and labeled; a deterministic fallback remains available. See AI Transparency.

Secure development and maintenance

Release validation includes formatting, linting, strict type checking, unit/integration/security tests, coverage gates, production build, dependency audit, Forge lint, environment deployment/installation checks, tenant acceptance where applicable and a separate Forge eligibility check. Manifest, scope, storage, dependency, egress, remote and Preview changes receive explicit security/capability review. Mederak Apps monitors Atlassian Marketplace security obligations and prioritizes remediation according to applicable Atlassian security timelines.

Vulnerability reporting

Report suspected vulnerabilities through Mederak Apps Service Desk and put Security report in the summary. In the first message, include a safe summary, affected App version/site, potential impact and a way to contact you. Do not include credentials, customer data or exploit material that could expose others; we will arrange a safer exchange if needed. Do not test against a customer or tenant you do not own or have written permission to assess.

Incident handling is described in Security Incident Response. Security questions may also be submitted through the same channel.

Assurance boundary

This page describes current design and verified release practices. It is not a claim of ISO, SOC 2, Cloud Fortified, FedRAMP, HIPAA or another certification. No certification is claimed unless it is expressly listed here in the future.