How to Find API Tokens and Secrets in Jira Automation Rules

Where tokens and secrets hide in Jira automation rules (flows) — web request headers, URLs, smart values — how to scan the export for them, and what to do first when you find one.

Nobody sets out to hardcode a secret. The path there is always the same: a rule needs to call an external service, Send web request needs an Authorization header, the header needs a value, and there is nowhere good to put it. So it gets typed into the field, the rule works, and the ticket is closed.

Two years later that value is still there. It does not expire, it is not in a vault, it is not in any inventory, and it keeps working after the person who created it has left the company.

Why automation rules are a blind spot

Secret scanning is a solved problem in repositories. Every serious CI pipeline greps commits for token patterns. Jira automation rules (flows) sit outside all of it: they are configuration, not code, they live in a database rather than a file, and nothing scans them.

The result is a class of credential that no audit covers. It is not in your repo scan, not in your secrets manager, not in your offboarding checklist.

Where they hide

• Authorization headers on Send web request — bearer tokens, API keys, sometimes a base64 basic-auth string that looks like noise until you decode it
• Tokens in the URL itself — ?api_key=… or ?token=… in the query string, or a Slack or Automation webhook URL with its secret in the path, which also ends up in logs. A login written as user:password@host is not recognised — check those by hand.
• A smart value compared to a literal, as in {{webhookData.token}} equals …, or a token in a variable set once at the top of a rule and reused below
• Webhook secrets and connector parameters kept inline because the rule had no other place for them

All four are structural patterns. They can be found by reading the rule's configuration, without knowing anything about the service being called.

Finding them without making it worse

There is an awkward property here: the export file you would use to check is itself full of the secrets you are looking for. Jira settings → System → Automation flows → More actions (…) → Export flows (Export rules on older sites) produces a file that should be treated exactly like a credential dump — not emailed, not dropped in a shared drive, not attached to a ticket. Header values marked Hidden are the one thing Jira leaves out of it.

Automation Map scans the export for these patterns and names the rule; in the rule's logic the masked value shows as a placeholder on the step that holds it. It masks the credentials it recognises before anything is stored, and the finding is in every edition, Basic included — security findings are never behind a plan. The ready-to-paste security ticket is on the Audit page, Advanced and Enterprise.

NOTE: We deliberately do not publish counts from customer instances for this finding, not even anonymised — a number alone tells an attacker something useful about a real organisation. Your own numbers stay yours.

What to do with one you find

1. Rotate it first. Assume it is compromised — it has been sitting in a configuration field readable by everyone who can open that rule in Jira's automation settings, and possibly in an export someone made years ago.
2. Put the new value somewhere better. Jira Cloud has no secret store for automation, so at minimum re-enter the new value in the web request header with Hidden ticked — it cannot be read back, and Jira drops it from exports. Better still, depending on what the rule calls: a Connect/Forge app credential, an OAuth integration, or a webhook the receiving service authenticates by signature rather than by shared secret.
3. Check the flow actor — the account the rule runs as. A rule executing as a departed admin has a second problem on top of the token.
4. Add rules to offboarding. When someone leaves, their tokens get revoked — but only if someone knows a rule is using one.

The honest limits

This is pattern matching on configuration. It finds credentials that look like credentials: recognisable header shapes, tokens in query strings and webhook paths, high-entropy strings in the places secrets normally go. A secret stored as something that looks like an ordinary value will not be flagged, and a harmless high-entropy string might be. Treat findings as a starting list, not a clean bill of health.

FAQ

Look before an auditor does

The tokens in your rules have been there for years, and they will keep working until someone finds them. Better that it is you.

👉 Automation Map for Jira — scan your rules for inline credentials