Security Best Practices Summary

This is the checklist to run against any AWS SDK-backed application, distilled from the rest of this section. It follows an OWASP-style progression: from what the SDK secures for free, through secrets, input handling, dependencies, IAM scope, and encryption/residency.

Work top to bottom on a new integration, and revisit it whenever the integration adds a new AWS service, a new user-facing input, or a new dependency.

How to Use This List

• Treat each item as an audit question against your own codebase, not just a reading exercise.
• The groups run from SDK defaults, through secrets and input handling, to dependencies, IAM, and encryption/residency.
• Most items apply whether you call AWS from boto3, the AWS SDK v3, or both in the same system.
• Revisit the list whenever a new service, new user input path, or new dependency joins a workload.

A - Know What the SDK Already Secures

1. Rely on TLS being on by default, but never disable it. Both SDKs encrypt every call in transit and validate certificates automatically - never set a flag to skip verification, even to work around a local proxy issue.
2. Trust the SDK's request signing. SigV4 signing happens automatically using whatever credentials the provider chain resolves - you never construct or verify a signature yourself.
3. Remember the shared responsibility model. AWS secures the infrastructure and the service API; you secure your credentials, your code's behavior, your data, and your IAM policies.
4. Don't mistake "it authenticated" for "it's secure." A successful call proves your credentials and policy allowed it - not that the policy is correctly scoped or the data is handled safely afterward.

B - Secrets Handling

5. Never hardcode an AWS access key, database password, or API token in source. Source it from Secrets Manager or a SecureString Parameter Store parameter at runtime instead.
6. Put a secret's identifier in an environment variable, never its value. The identifier (a SecretId or parameter name) is safe to log; the value it points to never is.
7. Never log a full request or response object that could carry a secret. Log specific, reviewed fields - an id, a version, a status - not the whole object.
8. Cache a fetched secret in memory rather than re-fetching it per request, refreshing only on a defined schedule or a rotation event.
9. Rotate immediately if a secret ever leaks into version control. Assume anything committed is compromised, even after a later commit removes it.

C - Input Validation for AWS-Bound Data

10. Never build an S3 key by concatenating raw user input. Allowlist the input, normalize the assembled key, and confirm it still starts with the intended prefix before the call.
11. Never string-concatenate user input into a DynamoDB expression. Bind every variable value through ExpressionAttributeValues, and variable attribute names through ExpressionAttributeNames.
12. Don't call this "SQL injection into AWS." Neither S3 nor DynamoDB has a SQL parser - describe the risk accurately as path traversal or expression injection so remediation stays targeted.
13. Revalidate on the server, even if the frontend already checked. Client-side validation is a UX nicety, not a security control.
14. Prefer a server-generated key (UUID or hash) over a raw user-supplied filename when the human-readable name isn't required, sidestepping path-traversal risk entirely.

D - Dependency Scanning

15. Scan Python dependencies with pip-audit (or safety) against the Python Packaging Advisory Database, including boto3 and botocore themselves.
16. Scan Node dependencies with npm audit, or a deeper supply-chain tool like Snyk or Socket, covering every @aws-sdk/* package.
17. Run the scan in CI on every PR, gated at a sensible severity threshold (e.g., high/critical), not just locally and occasionally.
18. Automate the fix half with Dependabot or Renovate so a patched version arrives as a PR the moment it's published.
19. Triage findings by exploitability before blocking a release - a CVE in an unused code path is lower urgency than one your integration actually exercises, but track it either way.

E - Least-Privilege Verification in CI

20. Validate every IAM policy change with ValidatePolicy before merge, failing the build on ERROR-severity findings.
21. Enforce hard guardrails with CheckAccessNotGranted - assert a policy never grants a specific forbidden action, as an automated CI gate.
22. Confirm an edit didn't widen an existing policy with CheckNoNewAccess, comparing against the prior merged version.
23. Lint IaC templates that create IAM resources with cfn-guard or an equivalent policy-as-code tool, before the stack deploys.
24. Pair CI-time checks with ongoing Access Analyzer unused-access review - one stops over-broad grants at merge time, the other trims what's granted but never used.

F - Encryption & Data Residency

25. Set SSE-KMS as the explicit default on S3 buckets, and use a customer-managed key when you need key-level audit events.
26. Encrypt DynamoDB and RDS/Aurora storage explicitly - RDS/Aurora encryption must be set at creation time and cannot be added after the fact.
27. Pin the SDK client's region deliberately rather than relying on an ambient default that could differ between environments.
28. Apply the same residency and encryption review to backups, replicas, and log destinations, not just the primary data store.

FAQs

Related

• Security for AWS SDK Code: Defaults and Gaps - the shared responsibility model behind group A.
• Secrets Handling: Never in Code, Never in Logs - the full pattern behind group B.
• Input Validation for AWS-Bound Data - the full pattern behind group C.
• Dependency Scanning for boto3 & @aws-sdk Packages - the full pattern behind group D.
• Least-Privilege Verification in CI - the full pattern behind group E.
• Data Residency & Encryption-in-Transit/At-Rest Checklist - the full checklist behind group F.

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

636f64656775696465732e696f7c6367696f313137377c323032363037