The Most Common Cybersecurity Mistakes Made by Jira Admins

Let’s imagine you’ve inherited a Jira instance. It’s been running for years. Nobody remembers or knows who set it up. The documentation is a PDF, which was last updated in 2017. Now, you’ve got 600 users, 47 custom workflows, three broken automations, and a SAML integration duct-taped to a legacy IDP. Welcome to the jungle. And here comes the security audit…

It’s hard to assume that most Jira admins are careless. They’re often overwhelmed. Jira isn’t just a project tracker. It’s not rare when, after some time, it becomes a labyrinth of configuration panels, permission schemes, and hidden behaviors that Atlassian sometimes changes – without notice.

It’s no surprise that Jira in such a shape is also an easier target for potential attackers. If so, all it takes is one simple mistake to a disaster, whether it’s due to handing out access to production logs, security incidents, or IP documentation.

Let’s check the most common mistakes that can burn Jira and the admin.

Mistake 1. Overexposed permission schemes

It won’t be a mistake to state that many organizations treat permissions like plumbing, following the thought: “If the water flows, we’re good.” Nonetheless, Jira permissions are recursive, conditional, and silent. And that’s a problem.

Take a quick look at the test below;

curl -u admin:password https://your.jira.domain/rest/api/2/project

If a user with no business in R&D views the internal project list, you’ve got a leak. It’s usually due to Browse Projects granted through an Anyone or jira-users group. Combining that with Manage Sprints or Edit Issues allows attackers to tamper with workflows unnoticed, which is even worse.

Permission audits are challenging because Jira doesn’t expose effective permissions natively. That means you’ll need either Assets (Insight) or scripts – like the one below – with ScriptRunner (groovy):

import com.atlassian.jira.component.ComponentAccessor
def projectManager = ComponentAccessor.getProjectManager()
def permissionManager = ComponentAccessor.getPermissionManager()
def user = ComponentAccessor.getUserManager().getUserByName("username")

projectManager.getProjectObjects().each { project ->
	def hasPermission = permissionManager.hasPermission(Permissions.BROWSE, project, user)
	if (hasPermission) {
    	log.warn("User has access to: ${project.getName()}")
	}
}

It may be surprising how many ghost accounts still have access to decommissioned projects.

Another interesting case is over-permissioned project roles. This is the part where the possibility of internal sabotage grows. This may be an exaggeration, but it is worth remembering that Jira makes it easier – or even more convenient – to give project-specific admin rights.

For example, when a given admin wants to let Team Leads manage sprints, a custom role is created by slapping on Administer Projects. And that’s it! 

In the meantime, that permission allows Team Leads to change workflows, edit screens, add fields, and inject scripts if Forge is enabled. One malicious custom field with an automation can:

• exfiltrate data
• trigger CI/CD builds
• flood Slack with unwanted data.

Mistake 2. Anonymous access enablement

Even though it seems impossible, such mistakes still happen. In some companies, it’s a quick fix for contractors or a leftover from public service desks or internal wikis. The challenge is that anonymous access applies to issues, attachments, and workflows. That’s an open door.

Take a quick test and run:

curl -s https://your.jira.domain/rest/api/2/issue/KEY-1234 | jq

If you get a 200 without an auth header, you have a problem. The fix doesn’t just turn off anonymous in Global Permissions. It’s also necessary to verify each project’s permission scheme. Ensure Browse Projects doesn’t include the Anyone group. Reason? Some setups bypass global restrictions entirely.

Jira Administration → System → Global Permissions → Browse Projects

In a situation where Anyone has permission, the whole tracking system becomes a public blog for obvious reasons. Then, all it takes is an unauthenticated curl to start scraping:

curl https://yourdomain.atlassian.net/rest/api/2/search?jql=project=DEV

From the API perspective, it doesn’t matter whether someone is logged or not. It has been instructed to omit that aspect.

Exposed Jira instances have the potential to leak hundreds of issues this way. That includes attachments and comments, not to mention AWS keys, JWT tokens in logs, etc. All get indexed by Google unless blocked in the robots.txt file.

Mistake 3. Reusing local admin accounts

It may be hard to believe, but many Jira admins still create service accounts using names like jira_admin, deployment, or svc-jenkins. These are often local and not tied to LDAP, SSO, or any other (and meaningful) identity provider.

And yes, in such configurations, admins tend to use shared passwords with no expiration, rotation, or audit trail.

A fine example may be a situation when the attacker uses a build_agent account. He utilizes it to escalate to Confluence, take over VPN configs, and pivot into AWS. During the process, it turns out that the password is a few years old, and nobody has used the account since Jenkins was migrated.

In the meantime, tying every account to a person or service principal via SSO is a standard. The same goes for setting up SCIM provisioning and using OAuth 2.0 (if possible). In other words, it’s impossible to improve anything if you don’t track it.

Mistake 4. Misconfigured webhooks

Webhooks, automation, and CI/CD triggers stay in the DevOps interest. However, each webhook is an outbound HTTP request to a configured URL. They often entail authentication headers or sensitive payloads.

Nonetheless, there are cases where Jira admins forget these requests are plaintext over HTTP – if you don’t force HTTPS. It’s even worse, as they point to public IPs in test environments with debug logging enabled. 

For instance, let’s look at the webhook config below (JSON):

{
  "url": "http://test-ci.example.com:8080/hook",
  "events": ["jira:issue_created"],
  "excludeBody": false
}

The URL leaks issue descriptions to a public endpoint. The latter can be easily exposed and scanned. This way, attackers know where issues come from and who owns them. In other words, encryption with signed tokens in webhook headers and payload monitoring are musts.

Mistake 5. Failing to back up (correctly)

Neglecting to properly back up Jira data is a serious oversight. Administrators responsible for such critical systems must treat data protection as a top priority, as failure to do so can have severe consequences for the organization.

Some still believe that backups are for disaster recovery. You can still find admins who perform backups haphazardly and on the run. Based on that, you state the obvious: poorly prepared backups are low-hanging fruit to take. Especially if they’re:

• unencrypted
• accessible from the same network as your production instance (mind-blowing)
• stored with default names like jira_backup.zip.

The above may seem absurd, yet it’s widely known that 80% of ransomware incidents in enterprise settings target unprotected backup locations first. It’s a natural move, but it doesn’t happen without a reason.

Above all, such locations are usually script-accessible when Jira admins schedule backups via REST or cron and dump them to shared volumes. For instance, take a bash below:

smbclient \\\\10.1.1.50\\backups -U guest
smb: \> dir
  jira_backup_2025_05_12.zip

This is a pure attack surface with an invitation. Of course, if your backup includes attachments, you practically handed over all files ever uploaded to a ticket. The conclusion here is simple. Jira backups must be encrypted and offloaded to separate networks. Restores should be validated monthly.

A far better and more secure solution is using dedicated software, like GitProtect.io, that is not limited to a sheer backup and restore mechanism. Covering every aspect of your Jira setup – including Jira Software, Jira Service Management, and Jira Assets – this backup and disaster recovery platform integrates seamlessly. During the backup process, the tool includes:

The described solution supports 3-2-1, 3-2-1-1-0, 4-3-2 (and other) backup rules. It also provides GitProtect Cloud Storage for free, regardless of the license.

The last word

All elements described above underline the simple fact that Jira resembles your company’s nervous system. That makes it a magnet for (cyber)threat actors. It may seem like a paranoid or even hapless reality, but the key here is precision. Why? Because any setting you missed or didn’t understand is a potential breach vector.

And every time the admin says, “It’s just Jira,” t reminds about an a human error of 2022 when Atlassian experienced the worst outage with over 700 Jira users not being able to access their data for more than a fortnight. A thousand companies were affected and faced potential losses because “someone trusted the wrong default.”

From the Jira admin perspective, there’s no such thing as “just” Jira, only Jira done right. Of course, there’s also incident response.

Which side are you on?

[FREE TRIAL] Ensure compliant DevOps backup and recovery with a 14-day trial 🚀

[CUSTOM DEMO] Let’s talk about how backup & DR software for Jira can help you mitigate the risks