{% messageCard title="Article note" %}
This is Part 2 of a series on building a secure serverless GraphQL API. While it's not mandatory to read {% link href="/articles/building-secure-serverless-graphql-api-part-1" ariaLabel="Part one of article series" %}the part 1{% /link %}, doing so can help understand the context better. This article delves into security-related aspects, whereas {% link href="/articles/building-secure-serverless-graphql-api-part-1" ariaLabel="Part one of article series" %}the part 1{% /link %} addresses fundamental GraphQL concepts and the process of building one.
{% /messageCard %}

## Authentication 

Authentication is the process of verifying the identity of a user or system. By performing authentication we can add needed context to the requests. AWS AppSync supports several authentication types:
* `API_KEY`,
* `AWS_LAMBDA`,
* `AWS_IAM`,
* `OPENID_CONNECT`,
* `AMAZON_COGNITO_USER_POOLS`.

In case of this application `AMAZON_COGNITO_USER_POLLS` is chosen as the primary authentication type. {% link href="https://aws.amazon.com/cognito/" ariaLabel="Amazon Cognito product page" %}Amazon Cognito{% /link %} is a fully managed identity and user management service. It provides an option to create user pools which are a user directories. Let's start by creating a user pool in serverless framework. Config used for this user pool sets a policy for a password (minimum length of 8) and user attributes. 

```yaml
UserPool:
    Type: AWS::Cognito::UserPool
    Properties:
        AutoVerifiedAttributes:
            - email
        Policies:
            PasswordPolicy:
                MinimumLength: 8
                RequireLowercase: false
                RequireNumbers: false
                RequireUppercase: false
                RequireSymbols: false
        UsernameAttributes:
            - email
        Schema:
            - AttributeDataType: String
                Name: name
                Required: false
                Mutable: true
```

With this defined, the next step is linking it to the AppSync API.

```yaml
authentication:
  type: AMAZON_COGNITO_USER_POOLS
  config:
    userPoolId: !Ref UserPool
```

### Secondary authorizer

This app is an example of an online store. Some operations, like `placeOrder`, should only be done by admins or logged-in users, while others should only be available on the frontend. To handle this, feature of AppSync can be used that allows having multiple authorizers. In this case, an API key will be used to let the frontend connect to AppSync and run queries. It's a good idea to regularly rotate API keys, so a 1-month expiration time was set for this one.

```yaml
additionalAuthentications:
  - type: API_KEY
apiKeys:
  - name: WebClientApiKey
    expiresAfter: 1M
```

When both authorizers are defined, the GraphQL schema can be updated to reflect those changes. By default, when multiple authorizers are specified and the schema doesn't use directives to specify which field, query, or mutation should be used by which authorizer, AppSync assumes that the default authorizer will be used for all of them. This means it is not possible to access any of them using secondary authorizers. So in case of queries `getProducts` and `getCategories` should be allowed to be executed by both logged-in and not logged-in users. `getOrders` should only be executed by logged-in users. That's why, under the query declaration, no schema directive is used, and the query defaults to the default authorizer.

```gql
type Query {
    getProducts: [Product!]
    @aws_api_key @aws_cognito_user_pools
    getCategories: [Category!]
    @aws_api_key @aws_cognito_user_pools
    getOrders: [Order!]
}
```

## Authorization

Authorization is the process of determining and granting permissions to a user or system to access specific resources or perform certain actions. It defines what an authenticated user is allowed to do within a system. In case of this application some mutations like `placeOrder` should be allowed to be executed by all logged-in users while others like `createProduct` only be a specified group of users, for example administrators. 

Authorization can be achieved by first creating a user group in Cognito User Pools and then specifying operations in the GraphQL schema that should only be invoked by members of this group by appending schema directives.


Let's start with creating user group
```yaml
AdminGroup:
Type: AWS::Cognito::UserPoolGroup
Properties:
    GroupName: Admins
    UserPoolId: !Ref UserPool
```

Let's update graphql schema, bear in mind that name of the group in schema must match name of the group specified in cognito configuration.

```gql
type Mutation {
    placeOrder(input: OrderInput!): Order!
    createProduct(input: ProductInput!): Product!
	@aws_cognito_user_pools(cognito_groups: ["Admins"])
    createCategory(input: CategoryInput!): Category!
    @aws_cognito_user_pools(cognito_groups: ["Admins"])
    startProcessingOrder(id: ID!): Order!
	@aws_cognito_user_pools(cognito_groups: ["Admins"])
    completeOrder(id: ID!): Order!
	@aws_cognito_user_pools(cognito_groups: ["Admins"])
}
```

## Applying least-privilege permissions to IAM roles

When creating set of permissions to roles to attached to lambdas or other resources, grant only the ones that are need to perform a task. This way even if something goes wrong there's a smaller chance that unwanted operations will be spread across more resources. 

Example of limited set of privileges attached to lambda:

```yaml
products:
  handler: src/functions/field/products/products.handler
  environment:
    PRODUCT_TABLE: !Ref ProductTable
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:GetItem
      Resource: !GetAtt ProductTable.Arn
```

Example of non limited set of privileges attached to lambda:

```yaml
products:
  handler: src/functions/field/products/products.handler
  environment:
    PRODUCT_TABLE: !Ref ProductTable
  iamRoleStatements:
    - Effect: Allow
      Action: "*"
      Resource: "*"
```

## Mitigating malicious operations

### Limiting query depth

GraphQL allows clients to request data in multiple ways, offering various entry points. This flexibility enables the creation of exceptionally large and nested queries, such as the following example where 

```gql
query NestedQueryExample {
  getProducts {
    categories {
      products {
        categories {
          products {
            categories {
              # And this goes on and on...
            }
          }
        }
      }
    }
  }
}
```

This can be easily fixed in AppSync by specifying `queryDepthLimit` property.

```yaml
queryDepthLimit: 3
```

### Rate limiting

API rate limiting is a technique used to control the number of requests a client can make to an API within a specific time frame. It helps prevent abuse, ensures fair usage, protects against DDoS attacks, and maintains the overall performance and reliability of the API. By setting limits, such as 1000 requests per hour, developers can manage traffic effectively and provide a better experience for all users.

This can be achieved by using {% link href="https://aws.amazon.com/waf/" ariaLabel="AWS WAF service page" %}AWS WAF{% /link %} service. AWS WAF (Web Application Firewall) is a security service provided by Amazon Web Services that helps protect web applications from common web exploits and attacks. It allows you to create custom security rules to block or allow specific traffic patterns, such as SQL injection, cross-site scripting (XSS) or enabling **rate limiting**.

Example of enabling WAF:

```yaml
waf:
  enabled: true
  rules:
    - throttle # limit to 100 requests per 5 minutes period
```

More advanced configuration can also be passed:

```yaml
waf:
  enabled: true
  rules:
    - throttle:
        limit: 200
        priority: 10
        aggregateKeyType: FORWARDED_IP
        forwardedIPConfig:
          headerName: 'X-Forwarded-For'
          fallbackBehavior: 'MATCH'
```

## Disabling schema introspection

Disabling schema introspection in a production environment is a security best practice often implemented to protect sensitive information about the application's GraphQL schema. Schema introspection allows clients to query the schema itself, revealing details such as data types, field names, and relationships. While useful in development for debugging and client-side tooling, exposing this information in production can potentially aid attackers in understanding the structure and vulnerabilities of the API. By disabling schema introspection, developers reduce the attack surface and mitigate the risk of unauthorized access or exploitation of the GraphQL API.

This can be achieved by specifying `introspection` property.

```yaml
introspection: false
```

## Observability and monitoring

On the aws docs {% link href="https://aws.amazon.com/compare/the-difference-between-monitoring-and-observability/" ariaLabel="AWS docs on observability and monitoring" %} GraphQL documentation site{% /link %}, such a definition is mentioned:

> Monitoring is the process of collecting data and generating reports on different metrics that define system health. Observability is a more investigative approach. It looks closely at distributed system component interactions and data collected by monitoring to find the root cause of issues. It includes activities like trace path analysis, a process that follows the path of a request through the system to identify integration failures. Monitoring collects data on individual components, and observability looks at the distributed system as a whole.

Following this definition let's look at 

### Observability

One of the services that enables to have a observability in a system is an {% link href="https://aws.amazon.com/xray/" ariaLabel="AWS X-Ray service page" %}AWS X-Ray{% /link %}. AWS X-Ray is a service that helps developers analyze and debug applications. It provides an end-to-end view of requests as they travel through different components of an application, helping to identify performance bottlenecks, errors, and dependencies across services. 

In order to enable X-Ray in AppSync `xrayEnabled` property must be specified. 

```yaml
xrayEnabled: true
```

When X-Ray we can introspect each trace from aws console.

![X-Ray trace](/assets/building-secure-serverless-graphql-api-part-2/x-ray.png)

### Monitoring

Individual components such as Lambda can be monitored with the help of {% link href="https://aws.amazon.com/cloudwatch/" ariaLabel="AWS CloudWatch service page" %}AWS CloudWatch{% /link %}.

![CloudWatch logs](/assets/building-secure-serverless-graphql-api-part-2/cloudwatch.png)


## Conclusions

Security is a far more complex subject then what was described here. With that being said guidelines described in this article are a nice starting point in making the apps that you build production ready.

{% link href="https://github.com/piotrek12101999/building-secure-serverless-graphql-api-part-2" ariaLabel="Link to github to full code repository" %}As always here's the link to the full code repository{% /link %}.

Discover the process of creating a secure serverless GraphQL API leveraging AWS Lambda, AWS AppSync, Amazon Cognito, AWS WAF, AWS X-Ray and DynamoDB. Implement BFF pattern with the power of GraphQL.

Part 2: Building secure serverless GraphQL API

Part 1: Building secure serverless GraphQL API

Idempotency is often overlooked in API design, yet crucial for reliability. Design and build asynchronous API that ensures robust performance and resilient operations.

Designing idempotent serverless systems

Learn how to create serverless RESTful API using API Gateway, AWS Lambda and DynamoDB. Build scalable, performant solutions in the cloud with this step-by-step guide.

#serverless

Part 2: Building secure serverless GraphQL API

Part 1: Building secure serverless GraphQL API

Designing idempotent serverless systems

Building Serverless REST API with Lambda and TypeScript