Connect: Does anyone encrypt the app secrets?

Various source say “data should be encrypted at rest”. Example from Atlassian:

If your app needs to store sensitive data or important configuration data, you should store that within your own infrastructure. Sensitive data should be encrypted at rest. App specific data that is used for security-specific cases should also be contained in your own app’s infrastructure.

I have trouble understanding what it means technologically. The shared secret in Connect apps are certainly highly sensitive:

  • Even if you don’t store customer data yourself at all,
  • Simply having the shared secret for an app that has “READ” permissions allows a hacker to read the contents of Confluence instances from all people who have installed your app: Jira issues, Pages (=trade secrets, confidential information), history, names associated with the history (=PII).
  • Of course the app secret isn’t PII, but it allows access to PII if leaked.

I notice the Spring Boot starter from Atlassian doesn’t encrypt the app secrets by default in the AtlassianHost table. I am not aware that it is a frequent practice in engineering to encrypt a database column.

Does anyone encrypt their app secrets?

1 Like

Yes we encrypt the install payload secrets, it is one of the most sensitive pieces of data we store. The single shared secret means that if that were to leak access to any instance an app is installed in is possible.


@aragot You are correct. This is a limitation of the current Connect Spring Boot and ACE framework implementations.

We are looking at what is required to support this in a way which allows an addon developer to hook in their preferred encryption service. The frameworks, themselves, will not provide the encryption, merely a mechanism to hook encryption into the flow.

I don’t have a timeframe for when this will be available at this moment.


@cmacneill can you pls reference documentation that outlines best practice to hook client secret encryption into the flow? Thanks.

Update: It looks like AWS DynamoDb - where the connect tenant table is stored provides encryption at rest by default.

Hi @UlrichKuhnhardtIzym1 expands on how the shared secret should be encrypted. Encryption-at-rest is a good start, but ideally the secret would be encrypted separately (this gives a good audit trail, and makes rotation/re-encryption easier). I’ll see if we can add something to the docs to help.

1 Like