{"id":6551,"date":"2025-05-09T13:59:20","date_gmt":"2025-05-09T13:59:20","guid":{"rendered":"https:\/\/gitprotect.io\/blog\/?p=6551"},"modified":"2025-11-20T14:47:23","modified_gmt":"2025-11-20T14:47:23","slug":"the-most-common-cybersecurity-mistakes-made-by-jira-admins","status":"publish","type":"post","link":"https:\/\/gitprotect.io\/blog\/the-most-common-cybersecurity-mistakes-made-by-jira-admins\/","title":{"rendered":"The Most Common Cybersecurity Mistakes Made by Jira Admins"},"content":{"rendered":"\n

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\u2026<\/strong><\/p>\n\n\n\n\n\n\n\n

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.<\/p>\n\n\n\n

It’s no surprise that Jira in such a shape is also an easier target for potential attackers<\/a>. 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.<\/p>\n\n\n\n

Let’s check the most common mistakes that can burn Jira and the admin.<\/p>\n\n\n\n\n\n

Mistake 1. Overexposed permission schemes<\/strong><\/h2>\n\n\n\n

It won\u2019t be a mistake to state that many organizations treat permissions like plumbing, following the thought: \u201cIf the water flows, we\u2019re good.\u201d Nonetheless, Jira permissions are recursive, conditional, and silent. And that\u2019s a problem.<\/p>\n\n\n\n

Take a quick look at the test below;<\/p>\n\n\n\n

curl -u admin:password https:\/\/your.jira.domain\/rest\/api\/2\/project<\/code><\/pre>\n\n\n\n
If a user with no business in R&D views the internal project list, you\u2019ve got a leak. It\u2019s usually due to Browse Projects<\/em><\/strong> granted through an Anyone<\/em><\/strong> or <\/strong>jira-users<\/em><\/strong> group. Combining that with Manage Sprints<\/em><\/strong> or Edit Issues allows attackers to tamper with workflows unnoticed, which is even worse.<\/p>\n\n\n\n
Permission audits are challenging because Jira doesn\u2019t expose effective permissions natively. That means you\u2019ll need either Assets<\/strong> (Insight) or scripts \u2013 like the one below \u2013 with ScriptRunner (groovy):<\/p>\n\n\n\n
import com.atlassian.jira.component.ComponentAccessor\ndef projectManager = ComponentAccessor.getProjectManager()\ndef permissionManager = ComponentAccessor.getPermissionManager()\ndef user = ComponentAccessor.getUserManager().getUserByName(\"username\")\n\nprojectManager.getProjectObjects().each { project ->\n\tdef hasPermission = permissionManager.hasPermission(Permissions.BROWSE, project, user)\n\tif (hasPermission) {\n    \tlog.warn(\"User has access to: ${project.getName()}\")\n\t}\n}<\/code><\/pre>\n\n\n\n
It may be surprising how many ghost accounts still have access to decommissioned projects.<\/p>\n\n\n\n
Another interesting case is over-permissioned project roles<\/strong>. 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.<\/p>\n\n\n\n
For example, when a given admin wants to let Team Leads manage sprints, a custom role is created by slapping on Administer Projects<\/em><\/strong>. And that\u2019s it! <\/p>\n\n\n\n
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:<\/p>\n\n\n\n