-
Suggestion
-
Resolution: Fixed
-
5
-
Problem Definition
Oftentimes users create rules to send web requests using tokens/keys in the authorization header. As tokens/keys act like passwords for accounts, this can bring security issues as those keys are exposed to other users in the instance that have access to the automation rules.
Suggested Solution
Create a new section in automation where admins can create smart value variables to be used in any automation rule, where those values will be managed only by the users the admins allow.
- is duplicated by
-
- Closed
-
- Closed
- is related to
-
- Gathering Interest
[JSWCLOUD-22729] As an admin, I want to be able to hide values in automation rules, e.g. web requests using tokens in header
Hi e6207b92a2be ,
I think that's the expectable and desirable behaviour, except for the fact that it is not being notified through a message.
Imagine you have used your own user credentials for setting a rule that targeted Jira REST API for reading a value and adding a comment to an issue, according to the information collected, just as an example of a harmless and legit good usage of the rule.
Now, think that someone else with bad intentions edits/copies your rule to delete all issues in the Jira instance... in your own name! since it would be using your credentials...
So, for me it is the correct behaviour for security reasons, but not well informed through the UI.
Thanks and regards
I was excited to use this functionality and it initially worked.
However, I found a couple of cases where the functionality breaks:
the header is obfuscated, the rule is saved, then a validation is performed in the "send web request" component > after this the obfuscated value is no longer passed to the API endpoint correctly.- an automation rule is copied with an already obfuscated header in the webhook component > the copy rule no longer passes the obfuscated value to the API endpoint correctly.
A fellow user has found a third case when the "send web request" component (webhook) with an obfuscated header is nested in the rule tree - see https://jira.atlassian.com/browse/AUTO-192
89403358cf11, I am looking forward for your feedback. Hopefully, you can address these.
It just doesn't make sense that the API token can only be shown during its creation (well done! 
) but it is forever displayed in the Automation Rule in plain text (area for improvement 
) together with the email of the user (even if it is enconded in base64) so that anyone with project admin access could potentially copy and use said credentials in a script...
This is a really big risk!
Atlassian, please, implement a way to hide the credentials from the extremely useful Send Web Request action! 
+1000. Send Web Request action is great, but for the fact that it exposes the credentials.
Please, implement a solution anytime soon!
+100
A must have feature...Its a big security risk for having to expose tokens in the header..viewable by anyone having access to the Jira project
Please bump up the priority of this ticket Jira Automation team. Much needed stuff
Same concern here. The web request automation feature is great. But it exposes the api keys. Is there not a way to mask them? Or to use a variable representing a secret from a secret store in jira?
I want this feature.
Send web request is a popular action. But, it encourages the leakage of API tokens if this suggestion isn't implemented.
I want to add some of my context around how this would be incredibly beneficial for the Automation product future. Enabling the ability to hide values will allow your customers to store sensitive tokens. You can build interesting "apps" within Automation with that ability. This would be incredibly useful and enable the ability to hide tokens or values of any kind you'd be meeting a lot of different security requirements.
Thanks!
Oh, I see and completely agree with your points, Ignacio. Yes, a message/warning on the component page will be very beneficial. I lost valuable time troubleshooting this.
Kalin