Forem: Éloi Alain

Clean authorization control in serverless functions

Éloi Alain — Tue, 28 Nov 2023 12:47:45 +0000

In this article, I walk you through some control points to clean up authorization code in your serverless functions.

Serverless applications have a lot of benefits. They are easy to deploy and scale. They are also cheap to run. 🤑 However, they come with a few drawbacks. One of them being authorization hard to get right. On this matter is easy to make mistakes, write poorly maintainable code and introduce vulnerabilities. 😱

🕷️ Access control code can be ugly

In a typical multitenant serverless application on AWS, where Lambda is integrated with API Gateway for each endpoint, you have to write authorization code. This is code that will check whether the user who originated the request is allowed to access data or perform an action.

While in a monolithic application, you can rely on a framework to help you with that, you are on your own with serverless functions.

As your application evolves and becomes more complex, this becomes hard to maintain and check for vulnerabilities.

Hopefully, you can come up with a good access control strategy if you properly structure your code. 🏗️

🤦‍♂️ Naive solution: authorization code in the business logic

Let's consider a simple multitenant application to manage files for organizations. The application has two personas: CEO and user. CEO can access all files within their organization. Users can only access files they have created.

A poorly designed function that handles the request to get a file might look like this:

// POORLY designed function

export const handler = async (event, context) => {
  // Check that the user is in the requested organization
  // 🐍 authorization with business logic not directly related to the use case
  const userId = context.requestContext.authorizer.userId;
  const organizationId = event.pathParameters.organizationId;
  const user = await getUser(userId);
  if (!user.organizations.includes(organizationId)) {
    return {
      statusCode: 403,
    };
  }

  // Retrieve the file
  // 🚀 business logic
  const fileId = event.pathParameters.id;
  const file = await getFile(fileId);

  // Deny access if the user is not CEO or the author is not the user
  // 🐍 access control happening late
  if (event.requestContext.authorizer.role !== 'CEO' && file.authorId !== event.requestContext.authorizer.userId) {
    return {
      statusCode: 403,
    };
  }

  return {
    statusCode: 200,
    body: JSON.stringify(file),
  };
};

🧅 Share authorization code that all your functions use

In many cases, you will have to write the same authorization code in multiple functions. For example, you might want to check that the user is in the requested organization. You can share this code in a middleware. If you are using AWS Lambda, you can rely on middy.

Using a middleware will separate authorization code from the business logic and make it much easier to read.

Organizing your code in layers helps a lot. For example, you can enrich the context with the user information in a middleware, before authorization, for later use in subsequent steps:

// Add the user to the context to use this information later in the authorization step
// src/middlewares/addUserToContext.ts

export const addUserToContext = async (event, context) => {
  const userId = event.requestContext.authorizer.userId;
  const user = await getUser(userId);
  context.user = user;
};

⏱️ Early check authorization

Denying a rogue access as early as possible is a good practice.

Frameworks like Spring and Nest have decorators that you can use as soon as your function definition.

Find a way to check authorization as early as possible in the function.

// src/handlers/getFile.ts

const getFile = async (event, context) => {
  // Check that the user is in the requested organization
  if (!context.user.organizations.includes(organizationId)) {
    return {
      statusCode: 403,
    };
  }

  // If the user is not CEO, add a filter to only retrieve the files created by the user
  const filters = {};
  if (event.requestContext.authorizer.role !== 'CEO') {
    filters.authorId = event.requestContext.authorizer.userId;
  }

  // Retrieve the file
  const fileId = event.pathParameters.id;
  const file = await getFile(fileId, filters);

  // Deny access if the user is not CEO or the author is not the user
  if (file === null) {
    return {
      statusCode: 404,
    };
  }

  return {
    statusCode: 200,
    body: JSON.stringify(file),
  };
};

export const handler = middy(getFile).use(addUserToContext);

Again, leverage middleware to extract the authorization code from the business logic. ⛏️ See the next section for a full example.

📁 Use file hierarchy to identify shared and specific code

Mind the file hierarchy. You should identify shared and specific code at a glance 👀 Below you can see that every handler might have a specific validateAccess logic, while shared middleware is available higher in the hierarchy.

src/
  handlers/
    getFile/
      getFile.ts
      index.ts
      validateAccess.ts
  middlewares/
    addUserToContext/
      addUserToContext.ts
      index.ts
    validateTenancy/
      validateTenancy.ts
      index.ts

The function now only contains business logic.

// src/handlers/getFile/getFile.ts
export const getFile = async (event, context) => {
  // Retrieve the file
  const file = await getFile(filters);

  if (file === null) {
    return {
      statusCode: 404,
    };
  }

  return {
    statusCode: 200,
    body: JSON.stringify(file),
  };
};

Middleware can be found at the handler definition level.

// src/handlers/getFile/index.ts
export const handler = middy(getFile).use(addUserToContext).use(validateTenancy).use(validateAccess);

Shared middleware to validate tenancy (user is requesting a resource in their organization).

// src/middlewares/validateTenancy.ts
const validateTenancy = async (event, context) => {
  // Check that the user is in the requested organization
  if (!context.user.organizations.includes(organizationId)) {
    return {
      statusCode: 403,
    };
  }
};

Specific middleware to validate access (user is requesting a resource they have access to).

// src/handlers/getFile/validateAccess.ts
const validateAccess = async (event, context) => {
  if (event.requestContext.authorizer.role === 'CEO') {
    return;
  }

  event.filters = {
    fileId: event.pathParameters.id,
    authorId: event.requestContext.authorizer.userId,
  };
};

Pro tip 🚀 prefer allow list based authorization over deny list based authorization. This is a best practice, that will deny access by default.

Useful links

AWS RESTful API
AWS Lambda middleware tooling: middy
With a proper code structure, you can easily evolve to API Gateway Lambda authorizers

Deliver perfect HTTP security headers with AWS CloudFront

Éloi Alain — Wed, 25 Jan 2023 15:30:01 +0000

– Did you just say security headers?

– Yes.

– Are you talking about CORS headers?

– No.

TL;DR

AWS CloudFront enables you to easily make your users browse safer with managed security headers. Quickly check your compliance with sls-mentor.

HTTP security headers: a very simple addition to your website to efficiently prevent attacks

In the last 5 years, I have worked in a dozen teams to develop and run web applications. However, I have learnt about HTTP security headers very late in my full stack developer journey. This is only very recently, when I joined Theodo, that I was explained what HTTP security headers actually are. 😮

HTTP security headers are a mechanism to protect your application from common attacks. They are, as their name suggests, a set of HTTP headers with security purposes. They are set by the server and read by the browser, which then applies the security policy described by the header.

HTTP security headers are good deployment practices. Thus, they fall under the responsibility of ops teams, rather than dev teams. But more and more, dev teams are also responsible for the deployment of their applications.

The table below shows a subset of HTTP security headers. The description mentions the common attacks that the header protects against. The recommended value column contains optimal header values to protect your users against these threats.

Name	Recommended value	Description
Strict-Transport-Security	`max-age=31536000`	Informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it using HTTP should automatically be converted to HTTPS. The user's inputs will never be readable by a man on the middle (except potentially the first call ever, which does not contain any sensitive information).
X-Content-Type-Options	`nosniff`	Prevents older browsers from guessing the content of files sent by the server rather than trusting the Content-Type header. This prevents the detection and execution of malicious Javascript in an image uploaded by an attacker and then retrieved by a victim.
X-Frame-Options	`SAMEORIGIN`	Prevents the display of the site in an iframe, and thus protects against click-jacking.
X-XSS-Protection	`1; mode=block`	Prevents rendering of the page if an XSS attack is detected.
Referrer-Policy	`strict-origin-when-cross-origin`	Prevents sending sensitive information (origin, path and query string) to another website or when the protocol is downgraded (HTTPS → HTTP)

An extensive list can be found on the Mozilla Developer Network (MDN).

These headers do not impact the application itself. Thus adding these can be done at a very low cost.

Side note on CORS headers

Let’s digress a little bit to mention the Cross Origin Resource Sharing (CORS) headers. As a web application developer, you certainly already have come across them. Otherwise, believe me, you will encounter them sooner or later. 😉

HTTP security headers differ from CORS headers because:

they strengthen security features of the browser (instead of weakening the same origin policy)
they integrate very well in your development journey 😂

Demystifying HTTP security headers on AWS

AWS mentions several methods to deploy your website. Let's focus here on S3 and CloudFront and see how to configure security headers.

S3

Amazon Simple Storage Service (S3) offers the option to host static websites. However, with this method, configuring HTTPS and all the more so HTTP security headers is not possible. 😮

CloudFront

On the contrary, HTTP security headers can be very easily enabled on CloudFront. If this is your first time dealing with CloudFront:

don’t worry, this is actually pretty easy and cheap
brace yourself, CloudFront’s performance is mind blowing

Let’s dive in!

The CloudFront service works by creating distributions. These describe how your content will be delivered to your users.

An option that CloudFront offers is managing headers policies for you. The service defines subsets of headers with relevant values (like the one above) that you can easily add to request and responses in the flow.

Head over to the CloudFront service in the console.

Create or modify the distribution of your choice. Here, let’s assume the origin is S3 (alternatively this could be your own HTTP server).

Now, you can look for the Response headers policy section and choose SecurityHeadersPolicy.

That’s it! See, this was quite straightforward.

Further thoughts

As I dived in this topic, I added a security check to the audit tool that I use in my team: sls-mentor. This is an open source audit tool that helps us enforce best practices on our projects. Don’t hesitate to try it and send feedback to the team via a GitHub issue, the project is actively maintained. 😉

In the future, I will improve this security check to support projects that use their own managed policies on CloudFront. sls-mentor will check for the presence of the headers, and make finer recommendations on each header.

Stay tuned!

sls-mentor 1.0.0 available now! Your Free Open Source audit tool for AWS architectures!

Éloi Alain — Tue, 20 Sep 2022 13:12:54 +0000

Hi there! sls-mentor 1.0.0 is now available! 🚀

TL;DR

sls-mentor is a command line tool that produces a detailed report of the improvements you can make to your AWS architecture.

As a developer, I use sls-mentor to ensure that my project meets the highest quality standards

sls-mentor is the result of a two-year journey learning and improving AWS architectures.

sls-mentor covers a wide range of concerns: green IT, costs, security and more below),
sls-mentor has a thorough documentation of its checks to help your team understand the underlying issues,
sls-mentor suggests detailed actions to solve issues,
sls-mentor provides a clear API for the community to maintain and add new checks,
sls-mentor is framework agnostic.

The one liner of your dreams

npx sls-mentor

How does sls-mentor work?

Under the hood, sls-mentor uses the AWS SDK to check your provisioned resources against a set of rules. As a result, sls-mentor is compatible with all frameworks (Serverless, CDK, Terraform, CloudFormation, ...).

sls-mentor is designed for you

I know... You know the installation process

Of course you can install sls-mentor globally to use it across all your projects.

npm install -g sls-mentor

Otherwise, you can add sls-mentor to your project's development dependencies.

npm install --save-dev sls-mentor

To help you quickly understand the improvements you can bring your infrastructure, a bit at a time, sls-mentor comes with tons of options to reduce the scope of the analysis in a run.

Focus the analysis on a specific CloudFormation stack

Use the option -c to focus the analysis on specific CloudFormation stacks.

npx sls-mentor -c my-stack

Focus the analysis on specific tags

Use the option -t to focus the analysis on specific tags.

npx sls-mentor -t Key=my-tag,Value=my-value

Because AWS has quite restrictive rate limiting policy, it may be required to use at least one option if you have really big stacks.

sls-mentor is optimized to reduce its number of requests. For projects with a lot of resources, it will throttle requests to respect AWS quotas. This might cause a longer analysis time.

sls-mentor is best run in your CI

I recommend adding sls-mentor checks to a recurring job in your CI platform to get a periodic report of the improvements you can bring to your infrastructure. Depending on how often your infrastructure changes, you can run sls-mentor once a day, once a week or once a month.

By default, sls-mentor will exit with a non-zero code if it finds any issue. I recommend keeping this default setting and optionally use your CI provider option to allow this failing job. This way, you will be notified of any issue, and you will not block your deployment flow. Otherwise, you can use the option --noFail to always exit with a success code.

CI snippets

GitLab CI

This snippet will run sls-mentor after merge.

sls-mentor:
  image: node:16.17.0
  stage:
    - post-deploy-test # the stage after your deployment
  extends:
    - .setup-cli # setup AWS CLI (export environment variables)
  needs:
    - install # the job that installs your dependencies
  script:
    - yarn sls-mentor -r eu-west-1 -c <stacks> # fill in the stacks you want to check
  allow_failure: true # allow the job to fail, when you want to run subsequent tests

Circle CI

This snippet will run sls-mentor at 01:00 on Sundays.

jobs:
  sls-mentor-checks:
    docker:
      - image: cimg/node:16.17.0
    steps:
      - checkout # checkout your code
      - setup-aws-cli # setup AWS CLI (export environment variables)
      - install # install your dependencies
      - run: yarn sls-mentor -p my-aws-profile -c my-stack-1 my-stack-2
workflows:
  weekly-sls-mentor-checks:
    triggers:
      - schedule:
          cron: '0 1 * * 0' # run at 01:00 on Sundays
          filters:
            branches:
              only:
                - main
    jobs:
      - sls-mentor-checks

⚠ You should be running at least Node v16 to get the appropriate return code.

Some issues are more important to you than others

That's why sls-mentor organizes the checks in 5 categories.

🌱 Green IT: this one is my favorite, it's about reducing your carbon footprint

💲 Costs: this one helps you reduce your AWS bill,

🔒 Security: you know, the thing that is important to you,

⚡ Speed: you know, the thing that is important to your users,

🧘 Stability: that's for your team.

To illustrate, let's consider the following two checks.

1. ARM – 🌱 + 💲 + ⚡

The default architecture for Lambdas functions is x86_64 but should be configure to arm64. Lambda functions that use arm64 architecture (AWS Graviton2 CPU) can achieve 34% better price performance than the equivalent function running on x86_64 architecture.

Full article on Lambda function architectures

2. S3 Intelligent Tiering – 💲

sls-mentor not only has checks for Lambda, but other AWS services as well. For example, the S3 Intelligent Tiering storage class is designed to optimize storage costs by automatically moving data to the most cost-effective access tier. For a small monthly charge, S3 Intelligent Tiering monitors access patterns and automatically moves objects that have not been accessed for a long time to lower-cost access tiers.

As I mentioned in the introduction, new checks are frequently added

We are currently working on a check to avoid infinite log retention in CloudWatch.

Starting from version 1.0.0, whenever a new rule is added, at least the minor version will be bumped.

⚠ If sls-mentor is configured to stop your deployment whenever a rule fails, do not to allow any minor version update (see semver), as the introduction of a new rule could suddenly stop your deployment.

sls-mentor: AWS Trusted Advisor's little brother?

On your path to a perfect AWS Cloud architecture, sls-mentor is a good first step before the advanced AWS Trusted Advisor.

sls-mentor's background is a different from AWS Trusted Advisor because rules are sourced from the community. Because sls-mentor uses the AWS SDK, power users can also add their own rules with maximum flexibility.

Solution	Cost	Source
sls-mentor	Free	Community
Trusted Advisor	Start from $29 / month (depends on your plan and monthly AWS charges)	AWS

In the end, both tools may be used together. ✨

About Kumo

This project was started at Kumo, a group of passionate developers highly experienced in Serverless architectures for the Web, to bring the highest quality solutions to our clients. sls-mentor has many valuable learnings of our team to help you learn faster.

Feel free to reach out to us on Twitter if you have any questions or feedback.

AWS Lambda 101: Shave That Bundle Down

Éloi Alain — Tue, 14 Jun 2022 13:05:44 +0000

This article is part of a series on sls-mentor, an open-source, highly configurable, automated best-practice audit tool for AWS serverless architectures.

The lighter, the better

A light bundle will positively impact your Serverless architecture for at least two reasons.

1. A light deployment package reduces the cold start of your Lambda function

Reducing the size of the bundle will reduce the time it takes to upload the bundle, and also significantly reduce the lambda's cold start.

You should use appropriate tools to bundle your Lambda functions with a minimal size. For example, the Serverless Framework, with the serverless-esbuild plugin, automatically bundles your code and uploads it to AWS.

2. AWS enforces quotas on deployment resources

Smaller bundles will help you respect AWS quotas, allowing more functions in your AWS account!

Resource	Quota
Lambda function deployment package (zipped)	50 MB
Lambda function deployment package (uncompressed)	250 MB
Total deployment packages	75 GB

sls-mentor is your solution to easily check the size of your bundles

sls-mentor now offers a new rule to warn you when uploading bundles over 5 MB.

sls-mentor comes with many rules to help you make the best decisions for your Serverless project. It will help you identify where your code can be optimized to achieve better performance at a lower cost.

sls-mentor how-to

npm install @sls-mentor/sls-mentor
npx sls-mentor -p <your_aws_profile> -c <your_stack_name>

sls-mentor is available on NPM. You will find instructions to use sls-mentor in your CI.

Forem: Éloi Alain

Clean authorization control in serverless functions

🕷️ Access control code can be ugly

🤦‍♂️ Naive solution: authorization code in the business logic

🧅 Share authorization code that all your functions use

⏱️ Early check authorization

📁 Use file hierarchy to identify shared and specific code

Useful links

Deliver perfect HTTP security headers with AWS CloudFront

TL;DR

HTTP security headers: a very simple addition to your website to efficiently prevent attacks

Side note on CORS headers

Demystifying HTTP security headers on AWS

S3

CloudFront

Further thoughts

sls-mentor 1.0.0 available now! Your Free Open Source audit tool for AWS architectures!

Hi there! sls-mentor 1.0.0 is now available! 🚀

TL;DR

As a developer, I use sls-mentor to ensure that my project meets the highest quality standards

The one liner of your dreams

How does sls-mentor work?

sls-mentor is designed for you

I know... You know the installation process

Focus the analysis on a specific CloudFormation stack

Focus the analysis on specific tags

sls-mentor is best run in your CI

CI snippets

GitLab CI

Circle CI

Some issues are more important to you than others

1. ARM – 🌱 + 💲 + ⚡

2. S3 Intelligent Tiering – 💲

As I mentioned in the introduction, new checks are frequently added

sls-mentor: AWS Trusted Advisor's little brother?

About Kumo

See also

AWS Lambda 101: Shave That Bundle Down

The lighter, the better

1. A light deployment package reduces the cold start of your Lambda function

2. AWS enforces quotas on deployment resources

sls-mentor is your solution to easily check the size of your bundles

sls-mentor how-to

See also