What Amplify's generated infrastructure looks like from a security perspective
When you run amplify push, Amplify creates IAM roles, Lambda functions, DynamoDB tables, Cognito User Pools, AppSync GraphQL APIs, and S3 buckets. Each of these resources has an access policy. Amplify's defaults are opinionated but not always security-first. Understanding what was generated and whether it matches your security requirements requires a practitioner to read IAM policies, not a developer to read Amplify documentation.
1. AppSync GraphQL resolver authorization
AppSync resolvers map GraphQL operations to backend data sources. Amplify generates these resolvers using the authorization directives you specify in your GraphQL schema (@auth rules). We test whether your @auth rules are correctly scoped:
- Owner authorization: We verify that queries and mutations restricted to the record owner (
allow: owner) cannot be executed by another authenticated user by manipulating the owner field or the identity claim in the JWT. - Group authorization: We test whether group membership checks in
@auth(rules: [{allow: groups, groups: ["Admin"]}])correctly derive group membership from the Cognito token rather than from a client-submitted claim. - Public access rules: We verify that any model with
allow: publicdoes not expose data that should be restricted to authenticated users.
2. Cognito User Pool configuration
Amplify creates and manages a Cognito User Pool for authentication. We audit the User Pool's configuration for the security-critical settings that Amplify does not always configure securely by default:
- Self-registration: Is open registration enabled? Anyone with the app client ID can create accounts. For B2B or invite-only applications, this should be disabled.
- Password policy: Does the policy enforce sufficient complexity? Amplify's minimum requirements often do not satisfy enterprise security standards.
- MFA enforcement: Is MFA optional or required? For applications handling financial data, optional MFA means most users have none.
- Token expiry: What are the Access Token and Refresh Token lifetimes? Default Cognito refresh tokens have a 30-day expiry, meaning a compromised session token grants access for up to 30 days without the user's knowledge.
3. S3 Storage access policy audit
Amplify Storage provisions an S3 bucket with IAM policies that define access levels: public, protected (read by all authenticated users, write by owner), and private (read and write by owner only). We test whether the generated bucket policies and Cognito identity pool roles enforce these boundaries correctly, or whether an authenticated user can read another user's private files by requesting the object key directly.
4. Overpermissive IAM roles for Lambda functions
Amplify Lambda functions (used for custom resolvers, authentication triggers, and REST API handlers) receive execution roles generated by Amplify. These roles frequently have broader permissions than the function requires. We audit every Lambda's execution role policy and flag permissions that exceed what the function's code actually needs, following the principle of least privilege.
Protected S3 storage read bypass via direct key access
During a security assessment of a Nigerian document management app built on Amplify, we found that the S3 storage level was set to "protected" for user uploads. The Amplify-generated IAM policy for authenticated users allowed reading any object under the /protected/ prefix if they knew the object key. By observing the object key format from our own uploads (prefix/userId/filename), we constructed keys for other user IDs and successfully downloaded their uploaded documents using our session credentials. Fix priority: high. Remediated by switching uploads to "private" storage level and generating time-limited pre-signed URLs for all document access.
Building a production application with AWS Amplify? Get a cloud security assessment before launch.
Book an Amplify Security TestFrequently asked questions
Does Amplify generate secure IAM roles by default?
Amplify generates IAM roles during backend provisioning. These roles often follow overly broad permission patterns (especially for unauthed guest roles and for Lambda function execution roles). We audit every generated IAM policy to verify that permissions follow least-privilege and that guest roles cannot access data intended for authenticated users.
What is the security risk of AppSync resolvers?
AppSync resolvers translate GraphQL operations into database queries (typically against DynamoDB). Resolver templates written in Velocity Template Language (VTL) can be vulnerable to injection if they construct query expressions using unvalidated input. We test resolvers for template injection and authorization bypass.
Can Amplify DataStore sync operations be exploited?
Amplify DataStore syncs data between the local device and AppSync. If the synchronization model's ownership rules are misconfigured, a user can sync records belonging to other users. We verify that ownership and group authorization rules are correctly applied to every data model.
Related reading
Blog: Supabase and Firebase security · AWS cloud infrastructure audit · Securing GraphQL APIs
Services: Penetration testing · Secure architecture review