EngineeringScoreExposure Medium
Rotate the exposed AWS access key
An AWS access key pair (an access key ID plus its paired secret) grants whatever IAM permissions are attached to it, from read-only access to a single bucket up to full account administration. A key pair that ends up in client-side JavaScript is exposed to anyone who loads the page, with whatever blast radius its permissions allow.
Why it matters
An AWS access key inherits whatever permissions are attached to it, which can mean reading files from storage buckets, spinning up billable compute, or altering infrastructure outright.
How to fix
- 1 Deactivate the exposed access key pair in IAM immediately (or delete it if unused elsewhere), then issue a new one. Deactivating is what stops it from working.
- 2 Move any use of the key to a server-side environment, IAM role, or secret manager; never ship an AWS access key to the browser.
- 3 Purge the old key from git history so it is not recoverable from a prior commit.
- 4 Redeploy and confirm the new build no longer ships any AWS credentials.
Common mistakes
- Deactivating the key in IAM but forgetting the access key ID and secret are a pair: an attacker only needs both, so leaving either half retrievable (e.g. in an old commit) is enough.
- Assuming a broad, admin-level policy is fine because 'it's just for one script': exposure risk scales with the permissions attached, not with how the key is used internally.
- Removing the key from the current build without purging it from git history, leaving it retrievable from any prior commit.
How to verify
- 1 Re-run the scan and confirm the AWS access key finding is gone.
- 2 Grep the built/deployed JavaScript bundle for the AKIA prefix to confirm no access key ID remains.
- 3 Confirm the deactivated key pair now fails authentication rather than assuming deactivation took effect.
Related checks
Ready to see where you stand?
Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.