Aiven Token

aiven_token

Severity

high

Vendor

Aiven

Family

API Token

Description

Aiven is a cloud data platform that provides fully-managed open source data infrastructure services: managed database services and data streaming and integration.

It exposes an API that uses different tokens for authentication:

Session tokens, created after log-in into the console. These tokens are revoked after log-out.
Personal tokens, created by users in the console or using the CLI.
Application tokens, linked to application users for non-human

Security

Any hardcoded Aiven Token is a potential secret reported by this detector. Both personal and application user tokens are detected.

Any adversary with the leaked token may access data with the same permissions as the token owner.

Tokens can have an expiration window configured, and expired tokens are removed automatically by the platform.

Examples

aiven_token = efiTZnULeUX...EpegYrw

Mitigation / Fix

Follow your policy for handling leaked secrets, which typically require revoking the tokens: Go to the console, authenticate as the owning user, click User Information (upper right icon) > Tokens, then click Revoke button for the leaked token (the starting characters are shown), or alternatively click Revoke all tokens.

You may use the Aiven CLI (avn) for revoking a token:
```
avn user access-token revoke <token|token_prefix>
```
Alternatively, for application tokens, go to Admin > Application users, select the application user that owns the token, and in the Authentication tokens section, click on … at the right and select Revoke.

Create a new token and take note of the value. You will need to replace references to the leaked token with the new one. Using the avn CLI:
```
avn user access-token create \
  --description <usage_description> \
  [--max-age-seconds <secs>] [--extend-when-used]
```
Remove the leaked token from the source code or committed configuration file, and replace it with the new token. But do not hardcode it again ! Environment variables, local files or secret vaults could be used for passing the token, instead of hardcoding the value, as documented in How to Prevent Hard-Coded Secrets.
Check access logs to ensure that the secret was not used by unintended actors during the compromised period.
To keep personal tokens secure, follow best practices like:
- Set a session duration to limit the impact of exposure.
- Refrain from letting users share tokens.
- Rotate your tokens regularly.
You may follow the Security Best Practices for Application Tokens as well.

You should consider any sensitive data in commits with secrets as compromised.

Remember that secrets may be removed from history in your projects, but not in other users' cloned or forked repositories.

Reference

Security Best Practices for Application Tokens