There are various ways to launch a website using AWS.

The key is to determine what type of website you want to launch.

Here are some examples:

• A company/marketing website
• A blog site
• A web application

Let’s explore how we could implement each type.

Launching a company/marketing website

Many business want an online presence.

They want to be able to include a website on their business cards and email footers.

They may focus most of their efforts on X, Instagram, or LinkedIn, for example, but they want that anchor.

They feel having a website makes them legitimate.

Yet, they are price conscious.

Using a website builder service that charges $20+ per month may be something they do not want to spend money on.

They might want to go with the DIY approach so they save some money and have the most control.

Let’s explore how AWS can help them build their website.

Use Case: Hosting a CMS site

A content management suite (CMS), such as Wordpress and Ghost, comes to mind as a solution to many people.

These platforms provide rich features for hosting your website or blog.

You can use Amazon EC2 to create a low cost virtual server.

You would follow the installation instructions to set up your server to meet the technical requirements and set up the server and web application.

It may take a few tries depending on how well written are the installation instructions and how comfortable you are with using Linux which is the common OS used for web servers.

EC2 charges by the hour and you may be able to pay as low as $10 per month.

If you take advance of AWS reservations, you can secure a discount if you reserve EC2 server for 1 year or longer.

Next, you will want to set up an SSL certificate so users can visit the HTTPS version of your site.

Search engines and web browsers will trust you more if you have a valid SSL certificate.

Some CMS will create the SSL certificate for you while others will require you install it.

You can use AWS Certificate Manager to create your SSL certificate.

They are usually free if you set them up for another AWS service which in our case would be EC2.

What is convenient is that you can configure it so AWS manages the annual certificate renewal for you.

Next, you may need set up an email server for the CMS to send emails.

You can use Amazon SES to set up an SMTP login for the CMS to use.

You will follow the steps on the AWS Management Console to create the SMTP login and put that information in the CMS settings page.

SES charges by the number of emails and it is very low cost.

You initially start with 200 emails from SES until you can verify the domain.

Follow the instructions in the AWS Management Console to verify the domain to unlock the limit.

Use Case: Static HTML Website Template

There are many website templates out there.

You can get some decent ones for free.

Or you can pay extra to get some nicer looking ones with fancy animations.

They are usually pretty low cost because they require you to make the edits.

You will need to know some HTML and basic CSS and JavaScript.

You will use your web browser to preview the code changes you made.

Once you are ready, you can upload all the HTML, CSS, JavaScript, icon, font and image files on an Amazon S3 bucket.

S3 storage is extremely cost effective.

You can enable the static web hosting feature on S3 but this will only give you HTTP access.

It is better to use a CloudFront distribution to serve the files from S3.

CloudFront will give you an HTTPS web address and cache your website files for faster load times.

You will need to add a policy to S3 allowing CloudFront to access the bucket.

You can use Amazon Certificate Manager and Route 53 to help you get a vanity domain so you are not using the auto-generated domain name.

The benefit of this approach is that you can save a lot of money on hosting costs because the S3 storage costs and the CloudFront data transfer fees are generally super cheap.

The downside is that the contact form that comes with the template will not work.

Most template sites give you a contact form that works with PHP.

Many template developers assume you will be hosting these files on a typical PHP web server.

This is where there be some extra manual effort.

You will need to modify the contact form to use JavaScript to make a fetch request to a Lambda function.

You will need to create a Lambda function that accepts the HTTP request, parse the HTTP body and send an email.

You can configure a Lambda function URL to make it web accessible.

You can use Amazon SES to send the email.

But you will make an API request to SES rather than using its SMTP server.

Next, you will need to define an IAM policy and assign it to the Lambda function.

The IAM policy will allow the send email action from the function to the SES service.

From my experience, I have only paid $0.50 per month or less for all the services.

The biggest cost is the Amazon Route 53 hosted zone, but everything else stayed within the AWS free trier.

Launching a blog site

You can use the use cases we already discussed to set up a blog site.

A typical CMS is already designed to support blogging.

Many HTML template have an example blog post page.

You will need to create a new HTML file for each post.

And you will need to update the page that lists all the blog post, the RSS file, and sitemap file.

If you still like the idea of low-cost serverless web hosting, there is a new use case we can explore.

Use Case: Static Site Generation

There are developer tools that can help you create web application.

Tools like Vue.js, Nuxt, React, and many others allow you to create website that can be deployed as HTML files.

These tools support what is called the JAMstack which relies on JavaScript, APIs and Markup.

You can configure these tools for static site generation mode.

This mode will create multiple HTML files that will make it more efficient to load a blog site.

Without this mode, you will get one huge HTML file that will put a lot of stress on the web browser.

You can deploy the SSG website the same way you deploy the static HTML website template.

Launching a Web Application

Again, you can deploy a CMS that is already a web application.

And you can deploy the a web application that was built with frontend framework like Vue.js, Nuxt, React or something else.

There is a little extra work to make the frontend framework fully functional.

Use Case: Web Application with a Web Server API

The JAMstack relies on APIs.

We already talked about using a Lambda function URL.

This is fine if you only need one API endpoint like for a contact form.

But it is not advisable for a full web application that has multiple API endpoints.

One way to create an API is to set up an EC2 instance to run Node.js, PHP or some other server language to accept HTTP requests.

This setup will work fine for low web traffic, but it will max out at some point.

You will need to start increasing the CPU and RAM as your web traffic increases.

But this will only take you so far.

At some point, there will be insufficient resources available to handle heavy traffic loads.

Before you get to this point, you will want to set up an Application Load Balancer.

The ALB will allow you to split the traffic among multiple servers.

With an advanced set up, you can have it create new EC2 instances as your demand spikes and delete them as it falls.

You will want to take advantage of EC2 images so you can spin up new instances with your web server already configured.

Use Case: Web Application with a Serverless API

Another solution is to set up API Gateway.

The API Gateway allow you to define your API endpoints.

You can use OpenAPI to set it up too.

Each API endpoint and method can point to other AWS resources.

You could have it point to an EC2 server and an ALB, but pointing to Lambda functions can be more efficient.

Each API endpoint should point to a Lambda function.

That way each endpoint and function code has a specific purpose.

Lambda already takes care of scaling.

API Gateway also does rate limiting to help you manage traffic spikes and it drops invalid API requests.

But you will have a lot of Lambda functions and each should have its own IAM policy.

You will have more resources deployed.

When API endpoint are retired, there will be more resources to clean up to avoid phantom resources that an adversary can exploit.

Conclusion

AWS allows you to deploy server-based and serverless solutions to meet your needs and use cases.

Some teams prefer pure server-based and other serverless.

Realistically, there could be a mix of both depending on what are your needs.

I wrote a book that teaches you step-by-step to build a serverless web application on AWS.

Get a copy if you’re interested in learning how to do this.

Mastering AWS Serverless Book

How do you launch a website on AWS? was originally published in Serverless CISO on Medium, where people are continuing the conversation by highlighting and responding to this story.

A recent article highlighted how files on an S3 bucket can be taken captive by a ransomware attack.

AWS S3 feature abused by ransomware hackers to encrypt storage buckets

How The Attack Happens

A malicious actor will do the following to ransom your S3 objects.

1. Find an AWS IAM keys that are exposed.
2. They access your AWS accounts with the IAM keys.
3. The discover which S3 buckets to which the IAM key has privileges.
4. They use the SSE-C encryption method to encrypt the bucket.
5. They mark the buckets for deletion in one week using lifecycle rules.

Even if you pay to have the objects decrypted, they might be automatically deleted before you even get a chance to decrypt them.

How To Protect Yourself

There are various ways to protect yourself from this type of attack.

Protect Your IAM Keys

1. Do not commit them to your repos.
2. Do not shared them in Slack or other messaging tools.
3. Rotate the keys on a schedule.
4. Delete them when you no longer need them.
5. Enforce MFA with the associated IAM user.

Stop Using IAM Keys

1. Use AWS STS to issue you a temporary IAM access keys that expire after one hour.
2. AWS IAM Identity Center that provides temporary IAM access keys from its web-based portal.
3. Use a Lambda function to perform the request. Assign the function to have the permissions to perform the desired changes. Securely invoke the function.

Use Least Privilege IAM Policies

1. Write your policies to only have the necessary privileges to get the job done and nothing else.
2. The IAM users should not have access to more resources than needed.

Replication and Backups

1. Use AWS Backup to back up your S3 objects.
2. Replicate your S3 objects to a bucket in another region.
3. Replicate your S3 objects to another AWS account.

S3 Features

1. Turn on object lock which prevents modifying S3 objects.
2. Use lifecycle management that moves old objects to cold storage which takes a long time to retrieve. This could mess up the ransomware scripts.
3. Use S3 versioning. Even if the object is deleted, any old version are still retained unless explicitly deleted.

Podcast Discussion

I discussed this topic on the LogiCast podcast.

Before you go

Did you know I wrote a book that will help you build a serverless application step-by-step?

Mastering AWS Serverless: Architecting, developing, and deploying serverless solutions on AWS (English Edition)

As an Amazon Associate I earn from qualifying purchases.

How To Protect Your AWS S3 Buckets from Ransomware was originally published in Serverless CISO on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Amazon Web Services Cloud Development Kit is an infrastructure-as-code solution. CDK allows us to write code (in JavaScript, TypeScript, Python, for example) to programmatically deploy resources in our AWS account.

CDK is written in TypeScript and uses the ts-node package to deploy. When we run the cdk command in the terminal, the npm package uses the ts-node package to transpile the CDK code before running it.

The issue

I was finding it was taking “forever” when running a cdk deploy or cdk synth command. When I was troubleshooting or developing code, I wanted faster deploys. I was using the cdk watch command to hotswap changes during development. This was a “little” faster but still felt super slow. I wanted to find out why these CDK commands were taking so long.

This was the solution

I will share the solution upfront. The rest of the post will share my findings.

I installed a new ts-node transpiler using npm.

npm i -D @swc/core @swc/helpers regenerator-runtime

I updated my tsconfig.json file to tell ts-node to use the new SWC transpiler. I added the ts-node property and the swc property under it.

{
  "ts-node": {
    "swc": true
  }
}

I noticed a significant improvement when running cdk and npx ts-node commands in the terminal.

Keep in mind this note from the SWC website:

SWC only transpiles the code and doesn’t perform type checking. Therefore, it’s recommended that you continue to use tsc for detecting any type errors.

How I found the solution

I realized that ts-node could be the issue. I write command line scripts with TypeScript. I use the npx ts-node myfile.ts command to execute them. They took a while to execute but did not think much about it. When I was getting frustrated by the CDK command start times, I started to realize the TypeScript script execution time was slow too.

I decided to investigate if they were speed issues with the ts-node package.

I found a GitHub issue where others expressed their concerns with the slowness of ts-node.

ts-node & nodemon takes 2 minutes to start; too slow · Issue #1070 · TypeStrong/ts-node

The discussion taught me about the SWC transpiler that can speed up the time ts-node uses.

SWC | ts-node

I installed the SWC packages and updated my tsconfig.json file. I noticed a significant improvement when using cdk deploy , cdk synth , cdk watch , and npx ts-node commands in the terminal. Development time was much faster now.

I updated my CI/CD pipeline that deploys multiple CDK apps and runs various TypeScript command line scripts. My CI/CD pipeline execution time dropped from 345 seconds to 74 seconds when I added the ts-node SWC setting. Wow! That’s over 75%.

I needed to share this finding with the CDK community. I submitted a GitHub pull request to add the SWC settings to the TypeScript app template.

chore(cdk): Speed up typescript app compile time by miguel-a-calles-mba · Pull Request #25089 · aws/aws-cdk

If the pull request is approved and merged, new CDK apps created by the cdk init command will get this speed boost.

Empirical testing

Let’s do some testing to see the effects of the SWC transpiler.

Let’s create a folder for our CDK apps. We will use the ~/cdkapps folder. Note: My setup uses Docker rather than installing Node.js directly onto my machine.

cd ~
mkdir cdkapps

The first test

We will create a new CDK app.

cd ~/cdkapps
mkdir test1-cdk
cd test1-cdk
npx cdk init app --language typescript

Let’s test the time it takes to synthesize an empty app.

time npm run cdk synth

The command sent this output:

real 0m38.681s
user 0m46.195s
sys 0m1.769s

It took 46 seconds to synthesize a CDK app.

Now let’s test with the SWC transpiler. (The command assumes the steps to add the SWC transpiler were already done.)

time npm run cdk synth

The command sent this output:

real 0m9.562s
user 0m9.105s
sys 0m0.703s

It took 9 seconds to synthesize a CDK app when using SWC. That’s an 80% improvement!

The second test

Now let’s create a new CDK app with one TypeScript Lambda function.

We will create a new CDK app.

cd ~/cdkapps
mkdir test2-cdk
cd test2-cdk
npx cdk init app --language typescript

Let’s add the packages to help with adding a Lambda function.

npm i -D @types/aws-lambda

Let’s create the Lambda function.

touch function.ts

Let’s create the function code.

/* ~/cdkapps/test2-cdk/function.ts */

import { Handler } from 'aws-lambda';

export const handler: Handler<Event> = async function(event, _context) {
  return;
}

Let’s create the function resource.

/* ~/cdkapps/test2-cdk/lib/test2-cdk-stack.ts */
import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as path from 'path';

export class Test2CdkStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new cdk.aws_lambda_nodejs.NodejsFunction(this, 'function', {
      functionName: 'function',
      handler: 'handler',
      runtime: cdk.aws_lambda.Runtime.NODEJS_18_X,
      entry: path.resolve('__dirname', '..', 'function.ts'),
    });
  }
}

Let’s test the time it takes to synthesize an app on a bare TypeScript Lambda function.

time npm run cdk synth

The command sent this output:

real 0m49.314s
user 0m58.874s
sys 0m3.818s

It took 58 seconds to synthesize a CDK app.

Now let’s test with the SWC transpiler. (The command assumes the steps to add the SWC transpiler were already done.)

time npm run cdk synth

The command sent this output:

real 0m18.985s
user 0m18.625s
sys 0m2.186s

It took 18 seconds to synthesize a CDK app when using SWC. That’s a 67% improvement.

Conclusion

Consider adding the SWC transpiler for ts-node to your AWS CDK apps. The time results will vary depending on your setup.

Before you go

Here are other posts you might enjoy.

• AWS CDK Serverless Cookbook
• Stop Installing Node.js and Global Npm Packages, Use Docker Instead
• Cloudflare v. AWS: A Comparison of Their Serverless Offerings
• How I Caused an Amazon API Gateway Denial of Service

More content at PlainEnglish.io. Sign up for our free weekly newsletter. Join our Discord community and follow us on Twitter, LinkedIn and YouTube.

Learn how to build awareness and adoption for your startup with Circuit.

Speed up AWS CDK deploys up to 80% was originally published in Serverless CISO on Medium, where people are continuing the conversation by highlighting and responding to this story.

A deep dive case study that highlights the importance of addressing the injection OWASP top 10 security risk.

Developers love Application Programming Interfaces (APIs) because they allow them to take advantage of services without building them. But do the developers who create the APIs feel the same way considering that the API exposes their service to potential mayhem from a security perspective?

I have worked with many vendors and used their APIs to integrate their services into my projects. Some are easy to integrate, and others are not so. In the end, the integration provides much value to my project. Furthermore, my skills and knowledge have increased through various trials of integrating third-party services.

In this case, I describe a lesson reiterated and reinforced throughout a specific integration effort. The OWASP Top Ten documents the ten most critical application risks. Developers and projects should take this risk seriously. The realization of these risks might result in significant damage.

This case study explores one specific OWASP Top Ten risk.

OWASP A03:2021-Injection

The injection risk was considered the highest by OWASP for several years before dropping to third in 2021. An injection allows an attacker to compromise, destroy or control a system. Input validation and sanitization are one way to prevent it. OWASP recommends: “The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface” [OWASP Top 10 A3:2021-Injection].

Seems like common sense. Why is this still ranked as the third highest risk if it should be evident to developers to protect against it?

Schedule and cost are likely the most prominent opponents of addressing this risk. Your software manager might tell the developer, “Just get it working because we need to release the product soon,” or “We are running over budget. Make a note and secure it later.” The developer might think, “It’s secure enough. Plus, we have firewalls and antivirus to protect against an intrusion.” Whatever the reasons might be, this simple solution often gets overlooked.

How I was Using the Vendor API

I was working on a script to promote our vendor data from one stage to another in the pipeline. A pipeline is a set of environments configured to promote development code to production. In our pipeline, we had a development, testing, and production environment. The scripts interfaced with the data in the development environment and created it in the testing environment. When all the tests passed, the scripts created the data in the production environment.

The API provided interfaces to log in, log out, retrieve data objects, create data objects, and delete data objects. The script workflow worked in the following way: log into one environment, retrieve the primary data objects, retrieve the child objects, log out, log into another environment, use the retrieved data to create the primary and child objects, and log out. Below is an example of how it worked.

#!/usr/bin/python
import vendor_api
import json

# log into the deveplopment environment
try:
    vendor_api.login(
        'username',
        'password',
        'development'
    )
except:
    exit(1)

# get primary object
# retrieves JSON structure
# {
#   "uuid": "primary uuid value",
#   "attribute1": "value1",
#   "attribute2": "value2",
#   "children": ["uuid1", "uuid2"]
# }

primary_object = json.loads(
    vendor_api.get(vendor_api.PRIMARY)
)

# get child objects one at a time
# retrieves JSON structure
# {
#   "uuid": "child uuid value",
#   "attribute1": "value1",
#   "attribute2": "value2"
# }

child_objects = []

for x in range(0, len(primary_object['children']):
    uuid = primary_object['children'][x]
    child_object = json.loads(
        vendor_api.get(vendor_api.CHILD, uuid)
    )
    if "uuid" in child_object:
        child_objects.append(child_object)

# log out
vendor_api.logout()

# log into the testing environment
try:
    vendor_api.login('username', 'password', 'testing')
except:
    exit(2)

# create primary object
# API documentation states 
# the following required structure:
# {
#    "attribute1": "value1",
#    "attribute2": "value2"
# }

try:
    vendor_api.post(
        vendor_api.PRIMARY,
        json.dumps(primary_object)
    )
except:
    exit(3)

# create child objects
# API documentation states 
# the following required structure:
# {
#    "attribute1": "value1",
#    "attribute2": "value2"
# }

for x in range(0, len(child_objects)):
    try:
        vendor_api.post(
            vendor_api.CHILD,
            json.dumps(child_objects[x])
        )
    except:
        print(
            "Failed to created child object {}".format(
                child_objects[x]['uuid']
            )
        )

# log out
vendor_api.logout()

exit(0)

Concerns With the Use of the API

Do you notice something wrong here? (Ignore my lack of coding excellence.) Did you notice I did not delete the uuid attribute from the primary_object object and child_objects objects or I did not delete the children attribute from the primary_object? Why are these issues?

Let’s assume the vendor had a strict API. When I passed uuid and children to vendor_api.post for vendor_api.PRIMARY object type, the vendor API should have returned an INVALID ATTRIBUTES response. A looser API would have simply ignored them without an error response. An extremely loose API would have accepted them. An extremely loose API might accept an injection such as an rm -rf / command.

How I Corrupted a Database with an Accidental Injection Attack

I was deep into testing, and my test scenarios kept failing. I could not understand why they were failing. I was confident I did my due diligence in the development environment; everything worked fine there. The same scenarios were failing in the testing environment. I eventually contacted the vendor to investigate what might be the issue. I needed the vendor’s help since they provided limited debugging capability and needed to debug their infrastructure.

Their first diagnosis: you are misusing the API. I explained my script logic over a phone call and emailed them my script. They admitted my script seemed fine.

Their second diagnosis: your test scenarios are incorrect. I explained my test scenarios over a phone call and emailed them my scenarios. They admitted my test scenarios were acceptable.

What Was the Source of the Issue?

They continued to investigate for a while and returned with their conclusion: I managed to create duplicate UUIDs across multiple environments in a system that required unique UUIDs globally. I inquired how this was possible. They admitted their API accepted all attributes and inputs for the child objects. They considered their primary objects the most critical information and took considerable efforts to secure that part of the API. Given the cost and schedule, they felt securing the child object portion of the API was less important. Luckily, I was a partner in discovering this vulnerability before their API was widely adopted or a malicious agent attempted to exploit this finding. It took the vendor a few days to secure the API and fix all the environments.

This situation depicted why Injection is still among the highest OWASP security risks.

This article was edited and originally published on secjuice.com.

Before You Go

More content at PlainEnglish.io.

Sign up for our free weekly newsletter. Follow us on Twitter, LinkedIn, YouTube, and Discord.

Interested in scaling your software startup? Check out Circuit.

Here are other articles you might enjoy.

• How I Caused an Amazon API Gateway Denial of Service
• Five scary Linux commands you should not run
• How to Remove Sensitive Data and Plaintext Secrets From GitHub

How a Lack of API Security Allowed Me to Wreak Havoc on a Database using Python was originally published in Serverless CISO on Medium, where people are continuing the conversation by highlighting and responding to this story.

About a couple of years ago, Cloudflare launched a new type of serverless offering. Their serverless solution allows us to deploy serverless functions at the edge and to host serverless websites served by a fast content delivery network (CDN).

What is serverless computing?

In short, serverless computing is a way to deploy code and solutions without managing a server. It is slightly different than a virtual machine (VM) in the cloud. Cloud VMs allow us to log into the server, whereas a serverless solution does not give us access to the server. Some serverless solutions use containers. (Containers are super small virtual machines that run the smallest operating system. Docker is an example of how we can run containers.) Other solutions run the code in isolated processes. The Cloudflare approach uses this approach.

What is the Cloudflare serverless solution?

Cloudflare launched their Workers platform that runs JavaScript at their edge network data centers. The JavaScript code runs in isolated runtime processes. Rather than creating and destroying containers, their approach runs the code in isolation from the other code. This improves execution time and reduces the time to start the process execution. (This is called cold start time, which includes the time to create the container and wait for it to run the code.) And since the code runs at the edge, the network latency times are shortened.

In addition to the Workers solution, they launched the Pages platform that runs a serverless website. We can use HTML files or a single-page application (SPA) like Vue.js or React.js to run our website. We can deploy a website without ever needing to manage a web server.

Both of these together allow us to create an SPA with its application programming interface (SPA), all running within Cloudflare and a deployed from a single git repository.

How to develop locally?

Vue.js, React.js, and other SPA frameworks allow us to run local servers before we deploy the final code to a web server or a serverless website. I will assume that we know how to do this or that we can read their developer docs to learn how.

Cloudflare has a Wrangler tool that allows us to develop Pages and Workers locally. We can test our build SPA (i.e., the code that is final code ready to go to the serverless website) and our Workers JavaScript functions.

SPA and Cloudflare local dev approaches assume we are installing everything on our machine. I prefer to develop in Docker containers to improve my cybersecurity and provide a consistent development environment to my development teams.

The rest of this post will share how my development environment uses Docker containers with Docker Compose and allows me to develop a Vue.js website and an API powered by Cloudflare Workers.

How do I set up Docker on my machine?

Follow the instructions in the “Stop Installing Node.js and Global Npm Packages, Use Docker Instead” to get set up.

How do we set up the project?

We are going to use a monorepo project. We will have two directories at the top-level: functions and vuejs directories.

# native terminal A
$ mkdir functions
$ mkdir vuejs

How to set up a Vue.js local dev server with Docker?

We create a docker-compose.yml file in the top-level directory with the following.

# docker-compose.yml
version: '3'
services:
  web:
    # runs the web server
    # docker compose run --rm --service-ports web
    # docker compose run --rm --service-ports web bash
    image: 'circleci/node:16-bullseye'
    user: 'circleci'
    working_dir: '/home/web/vuejs'
    environment:
      - 'NODE_ENV=development'
    volumes:
      - './:/home/web'
    ports:
      - '8080:8080'
    # runs the web server and exposes the 8080 port
    command: 'npm run dev -- --host'

This configuration will allow us to run a container named web that hosts the Vue.js local web server. We are using Vite.js as the local web server that runs the local web server.

We start the web container and get a bash terminal:

docker compose run --rm --service-ports web bash

The --rm flag destroys the container after closing it, and the --service-ports flag exposes the web server 8080 port to our machine. The web parameter starts that container, and the bash parameter tells it to run bash.

# web container's terminal
circleci@a1b2c3d4e5f6:/home/web$ 
# set up your vue application as needed

We start the web container in another terminal window:

# native terminal B
docker compose run --rm --service-ports web

We now have a local web server that we can visit http://localhost:8080 and use it to preview our website.

Note: We may want to change the web name to vuejs if that helps us keep track of the container names.

How to set up Cloudflare Pages functions with Docker?

We add the following code to our docker-compose.yml file right after the previous code.

# docker-compose.yml
services:
  web:
    # omitted for readability
  wrangler:
    # run CloudFlare Pages functions using wrangler
    # docker compose run --rm --service-ports wrangler
    # docker compose run --rm --service-ports wrangler bash
    image: 'circleci/node:16-bullseye'
    user: 'circleci'
    working_dir: '/home/wrangler'
    environment:
      - 'NODE_ENV=development'
    volumes:
      - './:/home/wrangler'
    ports:
      - '8081:8081' # port for the api
      - '8976:8976' # port for wrangler
    # serves our build Vue.js app and runs the Workers
    command: 'npx wrangler pages dev ./vuejs/dist --port 8081'

This configuration will allow us to run a container named wrangler that hosts the functions using the Cloudflare wrangler tool.

We start the web container and get a bash terminal:

# native terminal C
docker compose run --rm --service-ports wrangler bash

We use the wrangler container’s terminal to set up our functions.

# wrangler container's terminal
circleci@a1b2c3d4e5f6:/home/wrangler$ npm init -y
circleci@a1b2c3d4e5f6:/home/wrangler$ npm i --save-dev wrangler
# add TypeScript support
circleci@a1b2c3d4e5f6:/home/wrangler$ npm i --save-dev typescript @cloudflare/workers-types @types/node
# create our functions
circleci@a1b2c3d4e5f6:/home/wrangler$ cd functions
circleci@a1b2c3d4e5f6:/home/wrangler$ touch tsconfig.json
circleci@a1b2c3d4e5f6:/home/wrangler$ mkdir api
circleci@a1b2c3d4e5f6:/home/wrangler$ cd api
circleci@a1b2c3d4e5f6:/home/wrangler$ touch categories.ts
circleci@a1b2c3d4e5f6:/home/wrangler$ touch posts.js

The functions/api folder hosts the Pages functions code that powers the API. We need to add the TypeScript config to our functions directory: thefunctions/tsconfig.json file.

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "CommonJS",
    "lib": ["ES2020"],
    "types": ["@cloudflare/workers-types"],
  },
  "include": ["**/*.ts"]
}

We start the wrangler container in another terminal window:

# native terminal D
docker compose run --rm --service-ports wrangler

The wrangler tool is now serving the API at http://localhost:8081 .

Note: If there is an error, you may need to do the next step and try again.

How do I build my Vue.js app in Docker?

We need to build our Vue.js app to run the Workers functions that run in our Pages app. The wrangler assumes we already have a ready-to-deploy SPA when it deploys the functions for that Pages website. As a result, we need a build SPA for local development for the Pages Workers functions.

We must access the web container’s command line interface to build the app.

# web container's terminal
circleci@a1b2c3d4e5f6:/home/web$ npm run build

How does my Vue.js app use the Workers API?

We will need a different URL depending on whether our app runs on a local web server or is hosted from Cloudflare Pages.

Since I am using Vite, we can define the API domain by doing the following:

const apiDomain = import.meta.env.DEV ? 'http://localhost:8081' : 'https://mysite.pages.dev';

When our site is in development, it will use the local web server address. Otherwise, it will use the Cloudflare Pages address.

Now we should add cross-origin resource sharing (CORS) headers to add some API protection.

Let’s create the first function.

/* functions/api/categories.ts */
export const onRequestGet: PagesFunction = (context) => {
  console.debug('context:', JSON.stringify(context, null, 1));
  const { request, env } = context;
  const headers = {
    'Access-Control-Allow-Origin': env['ENV_NAME'] === 'development'
      ? 'http://localhost:8080'
      : 'https://mysite.pages.dev',
    'Access-Control-Allow-Methods': 'GET',
    'Access-Control-Max-Age': '86400',
  };
  console.debug('headers:', headers);
  return new Response(JSON.stringify([{
    id: 1,
    title: 'Category 1',
  }]), { headers });
}

Let’s create the second function.

/* functions/api/posts.js */
export const onRequestGet = (context) => {
  console.debug('context:', JSON.stringify(context, null, 1));
  const { request, env } = context;
  const headers = {
    'Access-Control-Allow-Origin': env['ENV_NAME'] === 'development'
      ? 'http://localhost:8080'
      : 'https://vote.hoahero.org',
    'Access-Control-Allow-Methods': 'GET',
    'Access-Control-Max-Age': '86400',
  };
  console.debug('headers:', headers);
  return new Response(JSON.stringify([{
    id: 1,
    title: 'Post 1',
  }]), { headers });
}

We can now use these APIs in our Vue.js app. For simplicity, I will add it to the top-level App.vue file.

<!-- App.vue -->
<script setup lang="ts">
  import { onBeforeMount, onMounted } from 'vue';
  /* the environment variable comes from Vite */
  const apiDomain = import.meta.env.DEV ? 
    'http://localhost:8081'
    : 'https://mysite.pages.dev';
  onBeforeMount(async () => {
    const categories = await (
      await fetch(`${apiDomain}/api/categories`)
    ).json();
    const posts = await (
      await fetch(`${apiDomain}/api/posts`)
    ).json();
  })
</script>
<template>
  <div></div>
</template>
<style scoped>
</style>

Conclusion

We can use Docker Compose to run containers that will allow us to develop a Vue.js (or other SPA) in one container and develop the Cloudflare Pages functions in another container.

Before you go

These are other articles you might enjoy:

• Launch a free website in 4 steps
• Stop Installing Node.js and Global Npm Packages, Use Docker Instead
• How I Caused an Amazon API Gateway Denial of Service
• Create a website on AWS with Serverless Framework plugins

Use Docker for Cloudflare Pages and Workers development was originally published in Serverless CISO on Medium, where people are continuing the conversation by highlighting and responding to this story.

Serverless or JAMstack websites allow small businesses, side hustles, and startups to launch no-to-low-cost websites with some elbow grease. Here are some steps I used to launch a free website for a non-profit startup.

Download a free or low-cost website theme

Wix, EditorX, and other website builder services are nice, but they are expensive. Why pay for a service when the website is updated infrequently? You can achieve the same outcome by downloading a website theme.

I used bootstrapmade.com to download a free website theme built with Bootstrap. I like using Bootstrap for websites because they are responsive. These sites will adjust the layout depending on the screen size. The website will be mobile and tablet friendly from the get-go.

Modify the theme

Knowing some basic HTML and CSS will help with modifying the site. You can just update the text that is already there. Knowing HTML and CSS will allow you to make simple edits like readjusting the layout, changing the colors, and updating links and images.

You can learn HTML and CSS for free from w3schools.com.

I used the FlexStart template and modified it as needed.

Sign up for GitHub and create a private repository

GitHub is a free git-based source control repository service. They will host your website code. All the files you just modified can be saved and maintained in the GitHub repository.

Sign up for an account on GitHub.com, create a repository for your website, download the GitHub Desktop app, and clone the repository using GitHub Desktop.

I create a private repository since my code is not open source.

Here are some YouTube videos that might help.

Sign up for a serverless, static website provider

You can use GitHub Pages, Cloudflare Pages, or a similar service to host your website by linking your GitHub repository. When you link the repository, both providers will automatically update your website when you make an update to the repository.

I used Cloudflare Pages because the website will be protected by Cloudflare security features.

Here are some YouTube videos that might help.

Conclusion

I explained how you could deploy a simple website in four steps. Instead of paying money to host your simple website, you can use services like Cloudflare Pages to host the website. You can use the money you saved to promote your project or startup.

I spent $0 on the website theme, GitHub repository, and Cloudflare Pages website. It took me about 3–4 hours to modify the theme to my liking and less than 30 minutes to get it up and running in Cloudflare Pages. I paid for a custom domain for about $12. Whenever I update the website code in GitHub, the changes are live in Cloudflare Pages in less than one minute.

Before you go

These are other articles you might enjoy:

• Be careful when using .env files
• Create a website on AWS with Serverless Framework plugins
• Earn passive income by browsing the web
• Advance your career by avoiding these ten mistakes

Launch a free website in 4 steps was originally published in Serverless CISO on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a former project, I worked within a serverless architecture running on Amazon Web Services. We used Lambda to run our function code, DynamoDB to host our database tables, and API Gateway to provide the application programming interface. The API Gateway provided an endpoint URI which redirected the HTTP payload to a Lambda function. The Lambda function made a query to a DynamoDB table to get data, and it responded to the API Gateway with that data. Finally, the API Gateway sent that data to the client.

We had an idea to optimize this process. The majority of the time, the data responded with the same content. That means we were calling the DynamoDB table to get the same data almost every time. We decided caching could reduce the impact on our functions and tables.

We enabled API Gateway caching so the API Gateway would send cached data. API Gateway would not send a request to the Lambda function but sent cached data instead. It seemed like a good idea at first.

We later noticed the API Gateway continued to serve cached data until the cache expired even after updating the data in the DynamoDB table. This was problematic because we wanted to serve the new data.

We decided to solve this by implementing a Lambda function that subscribed to DynamoDB table streams. The streams sent events when the DynamoDB table had write/delete/update activity. Whenever the second Lambda function received a DynamoDB stream event, it would make an AWS SDK API call to the API Gateway to clear the cache.

Again, it seemed like a good idea until we found unexpected behavior. The DynamoDB streams started sending old events in batches. The second Lambda function received multiple, outdated stream events. Each event resulted in a clear-cache request to the API Gateway. In time, the API Gateway started rate limiting the AWS SDK API calls.

While the AWS SDK API calls were rate limited, the performance of the API endpoints was also affected. The endpoints stopped responding to HTTP requests! It seemed the API Gateway experienced an internal Denial of Service attack.

Sometimes, what seems like a good design could have adverse effects. When working with event-driven architectures and serverless architectures, it is good to assess what might happen when the non-ideal occurs. In this story, DynamoDB streams should have only sent new events that happened infrequently, but it started sending old events that were no longer relevant.

A code review might have caught this issue had we considered all the negative-path scenarios (i.e., non-ideal or malicious inputs). The Lambda function should have done input validation to only act on an event that was X minutes old, came from the correct table, and had the proper action (e.g., update).

An architecture review could have caught the issue had we explicitly defined when the DynamoDB table was updated and when the API Gateway cache should be cleared. In this case, the table was only updated in the CI/CD deployment pipeline. Having the CI/CD pipeline make the AWS SDK API call to clear the API Gateway cache would have been more appropriate.

Conclusion

I hope this story highlighted how a well-meaning design could result in an undesired outcome. In this example, an internal Lambda function made excessive calls to the AWS SDK API, resulting in a Denial of Service attack on the API Gateway. We might avoid these types of situations by analyzing the architecture, doing a thorough code review, and brainstorming negative-path scenarios.

I shared this lesson in the Serverless Security book and the OWASP 20th Anniversary event.

What is Serverless Security on AWS, Azure and Google Cloud?

Before you go

These are other articles you might enjoy:

• AWS CDK Serverless Cookbook
• Create a website on AWS with Serverless Framework plugins
• If you build it, you should break it.
• When to use ?? and || in JavaScript and TypeScript
• Five scary Linux commands you should not run

More content at PlainEnglish.io. Sign up for our free weekly newsletter. Follow us on Twitter, LinkedIn, YouTube, and Discord. Interested in Growth Hacking? Check out Circuit.

How I Caused an Amazon API Gateway Denial of Service was originally published in Serverless CISO on Medium, where people are continuing the conversation by highlighting and responding to this story.