Authentication & Credential Rules Checklist

Leaked AWS credentials are the fastest route to a security incident and a surprise bill.

This checklist is the highest-impact page in the section. Walk it against any code that constructs an AWS client.

How to Use This List

Each item is a checkbox rule with a one-line rationale; check it against your own code as an audit.
Rules are grouped A through E, running from "where credentials come from" to "what to do when one leaks."
The rules are language-agnostic: they hold identically for boto3 and AWS SDK for JavaScript v3.
Treat groups A and B as non-negotiable for every project; groups C through E scale with how sensitive the workload is.

A - Never Hardcode Credentials

Never put access keys in source code. Hardcoded keys end up in git history and are scraped from public repos within minutes.
Never commit credentials to a config file that ships. Keep .aws/credentials, .env, and secrets files out of the deploy artifact and out of version control.
Let the SDK's default credential chain resolve credentials. It searches environment variables, shared config, and IAM roles in order, so you rarely pass keys by hand.
Do not pass access keys as constructor arguments in application code. Passing aws_access_key_id / credentials literals defeats the chain and invites hardcoding.
Do not build credentials from string concatenation or templated config. Any place a key becomes a string is a place it can be logged or committed.

Let the default chain do the work - construct the client with no keys at all.

# --- Python (boto3) ---
import boto3
 
# Correct: no keys. The default chain finds env vars, shared config, or an IAM role.
s3 = boto3.client("s3", region_name="us-east-1")

// --- TypeScript (AWS SDK v3) ---
import { S3Client } from "@aws-sdk/client-s3";
 
// Correct: no keys. The default provider chain resolves credentials.
const s3 = new S3Client({ region: "us-east-1" });

B - Prefer Roles Over Long-Lived Keys

Use IAM roles on EC2, ECS, and Lambda. Attach a role and the SDK picks up temporary credentials automatically, with no keys to store.
Use IAM Identity Center or sso profiles for human developers. Short-lived SSO sessions beat long-lived access keys on a laptop.
Assume roles for cross-account access. Use STS AssumeRole (or a profile with role_arn) instead of copying another account's keys.
Prefer temporary credentials everywhere. Temporary credentials expire on their own, so a leak has a limited lifetime.
Reserve static access keys for the rare case with no role option. If you must use one, scope it tightly and rotate it on a schedule.

C - Keep Secrets Out of Code and Logs

Never log the resolved credential object. Do not print the credentials, the session, or the Authorization header while debugging.
Redact credentials in error reporting. Ensure exception handlers and crash reporters do not serialize the credential provider.
Store non-role secrets in a secret manager. Use AWS Secrets Manager or SSM Parameter Store (SecureString) rather than environment variables baked into an image.
Do not echo credentials into CI logs. Mask secrets in your CI system and avoid printenv-style debugging in pipelines.
Keep credentials out of URLs and query strings. Never embed keys in a link, a webhook, or a pre-signed URL you then log.

D - Configure Resolution Explicitly

Pin the region explicitly. Set region_name / region (or AWS_REGION) so the call does not depend on ambient defaults.
Use named profiles for multi-account local work. Select a profile per account rather than swapping keys in and out of one file.
Do not hardcode endpoint URLs to inject credentials. Let the SDK resolve endpoints; overriding them to sneak in static config freezes the partition.
Scope credentials to least privilege. Grant only the actions the code actually calls so a leaked credential does limited damage.

Read the caller's identity when you need to confirm which credentials resolved.

# --- Python (boto3) ---
import boto3
 
sts = boto3.client("sts", region_name="us-east-1")
who = sts.get_caller_identity()   # confirms which identity the chain resolved
print(who["Arn"])                 # never print the credentials themselves

// --- TypeScript (AWS SDK v3) ---
import { STSClient, GetCallerIdentityCommand } from "@aws-sdk/client-sts";
 
const sts = new STSClient({ region: "us-east-1" });
const who = await sts.send(new GetCallerIdentityCommand({}));
console.log(who.Arn); // confirms the identity; never log credentials

E - Rotate and Respond to Leaks

Treat any exposed key as already compromised. If a key touches a public repo, a screenshot, or a chat, rotate it immediately - do not wait for proof of misuse.
Deactivate then delete leaked keys. Deactivate first to catch anything still using it, confirm nothing breaks, then delete.
Scan commits for secrets before they merge. Run a secret scanner (for example git-secrets or a pre-commit hook) so keys never reach history.
Rotate long-lived keys on a schedule. Set a rotation interval and enforce it, so even undetected leaks have a bounded lifetime.

FAQs

Why is hardcoding a key so dangerous?

Committed keys are scraped from public repositories within minutes and used to launch resources for crypto mining. The result is a large bill and a security incident at once.

What is the default credential chain?

The ordered search the SDK runs to find credentials: explicit config, environment variables, shared config files, then instance, container, or Lambda IAM roles.

Why prefer roles over access keys?

Roles supply temporary credentials that rotate automatically and expire. There are no long-lived keys to store, leak, or forget to rotate.

How should developers authenticate locally?

With IAM Identity Center (SSO) profiles or named profiles that assume roles. These give short-lived credentials instead of static keys sitting on a laptop.

Where should I store secrets that are not roles?

In AWS Secrets Manager or SSM Parameter Store as a SecureString. Fetch them at runtime rather than baking them into an image or a committed file.

Is it safe to log the Authorization header when debugging?

No. It contains the SigV4 signature derived from your secret key. Redact credentials and signed headers from all logs and error reports.

What do I do the moment a key leaks?

Treat it as compromised. Deactivate it, confirm nothing legitimate breaks, then delete it and investigate what the key could reach.

How do roles help across accounts?

You assume a role in the target account with STS instead of copying its keys. The credentials are temporary and scoped to that role's permissions.

Does pinning the region have anything to do with credentials?

Indirectly. Explicit region config makes resolution reproducible, so calls do not silently go to the wrong region with credentials that may not be valid there.

How do I stop keys reaching git in the first place?

Run a secret scanner as a pre-commit hook and in CI. It blocks commits that contain key-shaped strings before they ever enter history.

Security Rules for SDK-Calling Services - least privilege, secret handling, and dependency scanning in depth.
Why AWS SDK Rules Exist - why leaked credentials are the highest-impact failure mode.
AWS SDK Rules Quickstart - the five starter rules, credentials first.
AWS SDK Rules & Best Practices Summary - the cross-cutting index for all checklists.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Authentication & Credential Rules Checklist

Leaked AWS credentials are the fastest route to a security incident and a surprise bill.

This checklist is the highest-impact page in the section. Walk it against any code that constructs an AWS client.

How to Use This List

Each item is a checkbox rule with a one-line rationale; check it against your own code as an audit.
Rules are grouped A through E, running from "where credentials come from" to "what to do when one leaks."
The rules are language-agnostic: they hold identically for boto3 and AWS SDK for JavaScript v3.
Treat groups A and B as non-negotiable for every project; groups C through E scale with how sensitive the workload is.

A - Never Hardcode Credentials

Never put access keys in source code. Hardcoded keys end up in git history and are scraped from public repos within minutes.
Never commit credentials to a config file that ships. Keep .aws/credentials, .env, and secrets files out of the deploy artifact and out of version control.
Let the SDK's default credential chain resolve credentials. It searches environment variables, shared config, and IAM roles in order, so you rarely pass keys by hand.
Do not pass access keys as constructor arguments in application code. Passing aws_access_key_id / credentials literals defeats the chain and invites hardcoding.
Do not build credentials from string concatenation or templated config. Any place a key becomes a string is a place it can be logged or committed.

Let the default chain do the work - construct the client with no keys at all.

# --- Python (boto3) ---
import boto3
 
# Correct: no keys. The default chain finds env vars, shared config, or an IAM role.
s3 = boto3.client("s3", region_name="us-east-1")

// --- TypeScript (AWS SDK v3) ---
import { S3Client } from "@aws-sdk/client-s3";
 
// Correct: no keys. The default provider chain resolves credentials.
const s3 = new S3Client({ region: "us-east-1" });

B - Prefer Roles Over Long-Lived Keys

Use IAM roles on EC2, ECS, and Lambda. Attach a role and the SDK picks up temporary credentials automatically, with no keys to store.
Use IAM Identity Center or sso profiles for human developers. Short-lived SSO sessions beat long-lived access keys on a laptop.
Assume roles for cross-account access. Use STS AssumeRole (or a profile with role_arn) instead of copying another account's keys.
Prefer temporary credentials everywhere. Temporary credentials expire on their own, so a leak has a limited lifetime.
Reserve static access keys for the rare case with no role option. If you must use one, scope it tightly and rotate it on a schedule.

C - Keep Secrets Out of Code and Logs

Never log the resolved credential object. Do not print the credentials, the session, or the Authorization header while debugging.
Redact credentials in error reporting. Ensure exception handlers and crash reporters do not serialize the credential provider.
Store non-role secrets in a secret manager. Use AWS Secrets Manager or SSM Parameter Store (SecureString) rather than environment variables baked into an image.
Do not echo credentials into CI logs. Mask secrets in your CI system and avoid printenv-style debugging in pipelines.
Keep credentials out of URLs and query strings. Never embed keys in a link, a webhook, or a pre-signed URL you then log.

D - Configure Resolution Explicitly

Pin the region explicitly. Set region_name / region (or AWS_REGION) so the call does not depend on ambient defaults.
Use named profiles for multi-account local work. Select a profile per account rather than swapping keys in and out of one file.
Do not hardcode endpoint URLs to inject credentials. Let the SDK resolve endpoints; overriding them to sneak in static config freezes the partition.
Scope credentials to least privilege. Grant only the actions the code actually calls so a leaked credential does limited damage.

Read the caller's identity when you need to confirm which credentials resolved.

# --- Python (boto3) ---
import boto3
 
sts = boto3.client("sts", region_name="us-east-1")
who = sts.get_caller_identity()   # confirms which identity the chain resolved
print(who["Arn"])                 # never print the credentials themselves

// --- TypeScript (AWS SDK v3) ---
import { STSClient, GetCallerIdentityCommand } from "@aws-sdk/client-sts";
 
const sts = new STSClient({ region: "us-east-1" });
const who = await sts.send(new GetCallerIdentityCommand({}));
console.log(who.Arn); // confirms the identity; never log credentials

E - Rotate and Respond to Leaks

Treat any exposed key as already compromised. If a key touches a public repo, a screenshot, or a chat, rotate it immediately - do not wait for proof of misuse.
Deactivate then delete leaked keys. Deactivate first to catch anything still using it, confirm nothing breaks, then delete.
Scan commits for secrets before they merge. Run a secret scanner (for example git-secrets or a pre-commit hook) so keys never reach history.
Rotate long-lived keys on a schedule. Set a rotation interval and enforce it, so even undetected leaks have a bounded lifetime.

FAQs

Why is hardcoding a key so dangerous?

Committed keys are scraped from public repositories within minutes and used to launch resources for crypto mining. The result is a large bill and a security incident at once.

What is the default credential chain?

The ordered search the SDK runs to find credentials: explicit config, environment variables, shared config files, then instance, container, or Lambda IAM roles.

Why prefer roles over access keys?

Roles supply temporary credentials that rotate automatically and expire. There are no long-lived keys to store, leak, or forget to rotate.

How should developers authenticate locally?

With IAM Identity Center (SSO) profiles or named profiles that assume roles. These give short-lived credentials instead of static keys sitting on a laptop.

Where should I store secrets that are not roles?

In AWS Secrets Manager or SSM Parameter Store as a SecureString. Fetch them at runtime rather than baking them into an image or a committed file.

Is it safe to log the Authorization header when debugging?

No. It contains the SigV4 signature derived from your secret key. Redact credentials and signed headers from all logs and error reports.

What do I do the moment a key leaks?

Treat it as compromised. Deactivate it, confirm nothing legitimate breaks, then delete it and investigate what the key could reach.

How do roles help across accounts?

You assume a role in the target account with STS instead of copying its keys. The credentials are temporary and scoped to that role's permissions.

Does pinning the region have anything to do with credentials?

Indirectly. Explicit region config makes resolution reproducible, so calls do not silently go to the wrong region with credentials that may not be valid there.

How do I stop keys reaching git in the first place?

Run a secret scanner as a pre-commit hook and in CI. It blocks commits that contain key-shaped strings before they ever enter history.

Security Rules for SDK-Calling Services - least privilege, secret handling, and dependency scanning in depth.
Why AWS SDK Rules Exist - why leaked credentials are the highest-impact failure mode.
AWS SDK Rules Quickstart - the five starter rules, credentials first.
AWS SDK Rules & Best Practices Summary - the cross-cutting index for all checklists.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Authentication & Credential Rules Checklist

Buscar en la documentación

Authentication & Credential Rules Checklist