AWS access key (AKIA) is in the front-end code

What it means in plain English

An AWS access key has two parts: an access key id, which starts with AKIA, and a secret access key. IAM's access key guide says not to put access keys or credential information in your application files. If the id is in the JavaScript, the secret is often next to it. Together they can call the AWS API as that user.

The sample id AKIAIOSFODNN7EXAMPLE in AWS's own docs is a placeholder, not a live key.

Likely causes

• The app uploads files to S3 from the browser with a long-term access key baked into the script.
• A .env value was given a public prefix, so the build included AWS_ACCESS_KEY_ID.
• The root account's keys were used. IAM says not to create access keys from the account's root credentials.

How to fix it, step by step

1. Search the built JavaScript for AKIA. Remove the access key id and the secret access key from the client.
2. Delete that access key in IAM and create a replacement only if a server still needs one. IAM says the secret access key can be retrieved only when you create it, so a lost or exposed secret means deleting the key and creating a new one. See the guide's "Update access keys" section.
3. Prefer temporary credentials, such as an IAM role, over a long-term access key. The same guide says to review alternatives to long-term keys before you create another pair.
4. Do the AWS call from a server route. The browser asks your server. Your server uses the role or the new key from an environment variable that is not shipped to the client.

How to check it worked

• The deployed JavaScript has no AKIA id (other than the public AWS documentation example, if you quoted it).
• CloudTrail shows the old key is no longer being used. IAM recommends CloudTrail for that check.

Sources

• https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html (opens in a new tab)