Script Studio: Security and Governance

This page describes who may use Script Studio, what a script is permitted to do, the limits that apply to execution, and where information is stored. It is intended for administrators responsible for approving the application and for those carrying out reviews.

1. Access

Script Studio is available only to Jira site administrators. The permission of the person making the request is verified for every action, including reading and saving files, creating fields and issuing access tokens.

Note: All site administrators share a single workspace, and there is no separate permission model within Script Studio. This reflects the fact that anyone able to administer the site can already perform any action a script could perform. What Script Studio provides is a record: every change is committed and every execution is retained. Advanced: how the permission check is applied

The Jira administration interface makes Script Studio visible only to administrators, but this is not relied upon as the control. Each request independently verifies the caller's administer permission against Jira, on the server. A request originating from outside the intended interface is therefore rejected in the same way.

2. What a script may do

In Jira

Scripts use the same permissions as Script Studio itself, which requests the following:

A script cannot exceed these permissions. The editor identifies any endpoint outside them while a script is being written.

Note: UI modification scripts are an exception. These run in the browser rather than on the server, and call Jira as the person filling in the form is permitted to, not as Script Studio is permitted to. A UI modification is therefore bounded by the permissions of whoever has the form open, which can be narrower, or broader in the specific sense of user-level access, than the application's own grant. See UI Modifications.

Its own storage

A script may create SQL tables of its own and read and write them between executions. This storage is separate from Jira and does not draw on the permissions above; see Script Storage (SQL). Table names that would collide with the application's own tables are refused.

Outside Jira

Server-side scripts have no general access to external networks. The only outbound communication performed is to the configured Git repository provider. Where an external system must be involved, the direction is reversed: a REST endpoint is published and the external system calls it.

3. Script variables and who can see them

A script variable is visible to context.variables according to how the script was started: a manual run sees every stored variable, while a schedule, an event, a field, a REST call or a workflow rule sees only the names the script has explicitly listed in an export const variables declaration. This is a deliberate allow-list, so that a secret set for one purpose cannot leak out through a script an administrator did not expect to have access to it. UI modification scripts, running in the browser, never receive variables at all. See Run Inputs and Script Variables.

4. External access to Script Studio

Two permissions govern external access to the Script Studio API, independently of the permissions held in Jira:

Nothing else is reachable through this route. Files and configuration are not accessible. An administrator must also authorise the calling application once, under Settings → Apps → Connected apps.

Endpoints that do not use Atlassian authentication are protected by an access token issued for that endpoint. See REST Endpoints. Advanced: how access tokens are protected

Each token is generated with 256 bits of randomness and is displayed only once. Only a cryptographic hash of the token is retained, and comparisons are performed in constant time so that no information is revealed by the time taken to reject an incorrect token. Tokens carry a recognisable prefix, so that one found in an external system's configuration can be identified as belonging to Script Studio.

5. Execution limits

Each way of starting a script has a time limit appropriate to the situation.

Resource limits

A script that exceeds its time limit is stopped and the execution is recorded as having timed out. Advanced: how a script is isolated

A script executes in a restricted JavaScript context rather than as ordinary application code, with the usual routes out of that isolation — reaching a live function belonging to the host, or compiling new code from a string at run time — deliberately closed off. This is the level of isolation the underlying platform makes available; it is not a claim that a script runs in a separate operating-system process.

6. Where information is stored

No information leaves the Atlassian data boundary other than what is deliberately sent: a push to a configured repository, a response to a call made to a published endpoint, or a call a UI modification script makes as the person using the form.

7. Editor extensions

The set of editor extensions is fixed by the vendor and ships with the application. An administrator cannot install additional extensions, from any source. Advanced: why this is fixed rather than configurable

An earlier release allowed an administrator to install compatible extensions from a public registry. This has been removed: every extension available in the editor is now reviewed and bundled with the application ahead of time, closing off a class of third-party code that would otherwise run inside a Jira administration page. The set changes only when the vendor updates it.

8. Personal data

Script Studio records the Atlassian account identifier of whoever last changed a file and whoever ran a script manually, purely as an audit trail. In line with Atlassian's platform-wide requirement for any app that stores account identifiers, these are included in the site's personal data report, and are cleared automatically if the corresponding Atlassian account is deleted.

9. Reviewing an instance

Note: 📹 Video placeholder — reviewing an instance: establishing what has been written using the file tree, the run history and the version history.

Related pages

• Run History and Diagnostics
• Source Control
• Script Storage (SQL)
• UI Modifications
• Run Inputs and Script Variables