Amplify is a Backend as a Service toolset with the goal of allowing developers to build cloud applications without advanced knowledge of the underlying infrastructure. The goal of focusing developers on creating business logic is laudable, but the toolset is not without weaknesses. Some weaknesses are missing features due to the product being new and these are understandable, but protecting customers needs to come before any new features and be priority #1 at AWS. Unfortunately, the Amplify authorisation tools do not sufficiently protect customers from exposing private data. Protecting customers has not been the highest priority.

Amazon has dealt with these issues before. S3, launched in 2006, is infamous for being hard for customers to configure securely. Data breaches from Capital One, Facebook, Verizon, Time Warner, and the USA Department of Defence are just some of the larger AWS S3 customers who have leaked data due to hard to understand and hard to verify security configurations. Some of the S3 data leaks are due to poor UX, with policies to lock down buckets to "any authenticated AWS user", which in practice means any user globally who spends 5 minutes registering an account. Basic security checks from an unauthenticated user would show these buckets are not available, where in reality a bad actor could scoop up company secrets in minutes.

Amazon has responded to these events by creating more tools to help customers identify open buckets and design better default policies. But there is only so much that can be done without breaking a decade of existing users. The result is that Chris Vickery, Director of Cyber Risk Research at UpGuard, is still seeing the same level of data breaches as before. The economic impact of not protecting S3 customers as priority #1 is measured in the billions of dollars. And now AWS Amplify is heading down the same path unless immediate corrections are made.

The crux of the issue is that Amplify markets its authentication modules to "provide Authentication APIs and building blocks for developers who want to create apps with real-world production-ready user authentication". Multiple AWS documents show how Amplify can accomplish proper authZ controls through Graphql directives. In the simple case of a note taking app, AWS sample code shows the following snippet, explaining to the user that "These items are only available to the user that created them":

type Note @model @auth(rules: [{ allow: owner }]) {
    id: ID!
    title: String!
    content: String
}

And to the casual reader, or even developer on a team using Amplify, this appears secure. Unfortunately, any user can read these notes as they are created or modified. How? Easy, every model by default creates a graphql subscription, which when called returns for any user an AWS IoT endpoint for MQTT over WSS, where you can subscribe to the returned topic and listen to all create and update events for a model. So much for users not needing to have advanced knowledge of the underlying infrastructure. On the majority of Amplify projects I have examined which proport to implement private data, subscriptions are available to read private information. While security is everyone's job, and every developer should be a security engineer, blame does not solely fall on these implementors, as they have been told that Amplify is doing the heavy lifting for them. Discovering the issue would have forced developers down the path of understanding unfamiliar languages and products they likely didn't know existed.

Until a month ago the Amplify documentation did not even acknowedge subscriptions can and do leak private information and how to turn them off, though users stumbling on the issue have notified AWS for much longer. Now, after an hour of reading time, and inside a page that takes at least 2 hours to read, is a note: "The @auth directive does not yet support subscriptions out of the box. Currently, you have two options for authorising subscription fields. You may turn off subscriptions by passing subscriptions: null to @model or you may write custom authorisation logic". Unfortunately, this note hasn't resulted in updates to "How to have a secure Amplify project in 60 minutes" tutorials, including those published by AWS, where users are likely to copy solutions as a starting point.

But its not only subscriptions, making models seachable likewise bypasses authentication. The AWS Amplify workshop, published and copyrighted by AWS, contains the following graphql schema:

type Photo 
  @model 
  @auth(rules: [{allow: owner}]) 
  @searchable {
    id: ID!
    album: Album @connection(name: "AlbumPhotos")
    bucket: String!
    fullsize: PhotoS3Info!
    thumbnail: PhotoS3Info!
    labels: [String!]
}

Again a casual reader, developer taking the workshop, or developer on a team using Amplify would assume this authentication role properly protects the Photo model. And the Amplify workshop page further states this schema "add[s] the ability for other people view and upload to our albums on a case-by-case basis". While that statement is true for the generated listPhotos and getPhotos graphql queries, it is not true for the searchPhotos query. Amplify users can verify this by inspecting the velocity template code generated by amplify during the deployment process. What they can't do is find this security bypass in the Amplify documentation. This authentication bypass has been flagged as an issue since November 2018 and appears to be a deliberate tradeoff to add a feature faster vs. integrate into the authorisation system. In the meantime developers are left on their own to discover this security hole, and learn to write velocity templates to implement their own security.

Everyone is responsible for building secure systems, including tool users and providers. Amplify users must evaluate and verify claims the tooling makes. Trust but verify. At the same time AWS markets Amplify as being able to abstract away complex back end and cloud technologies, and by implication state they are shifting the dividing line in the shared responsibility model to take on additional security responsibilities. And it is disappointing that this responsibility is being marketed to developers when the Amplify tool does not fulfill its obligation to create tools to properly control sensitive data.

Some Amplify marketing claims have failed the verification test. Users do need to worry about spending time on the heavy listing of configuring and securing multiple different cloud back-end services to power their applications. Failure to maintain responsibility for security will put businesses and their customers at risk.

These security issues can be overcome by users implementing additional custom logic and understanding more of the cloud technologies Amplify is creating on their behalf. Amplify does not have inherent security issues, and the tools can be evolved to create solutions that satisfy the marketing and tutorial claims. But some changes to Amplify may introduce breaking changes for existing users. And everyday these known issues are not addressed, more users will have implemented insecure systems and trap AWS into less than ideal upgrade paths. The Amplify team is in control over how many news stories in the next decade will discuss security breaches due to mis-configured Amplify APIs.

I hope the above will highlight to existing users they need to check the security of their own systems for these risks. And I hope AWS re-focuses their efforts on Amplify to follow their CTOs advice that protecting customers comes before any feature development.