Unleashing the power of serverless: a deep dive into web form deployment with our serverless plugin

Web forms are the lifeblood of online interaction, serving as the primary conduit between users and web services. However, deploying these forms can often feel like navigating a labyrinth. Fear not, as we're here to guide you through this maze.

In this post, we'll dissect the anatomy of form deployment, comparing the traditional server-side method with the modern serverless approach. We'll also shed light on why serverless may be the best choice, discuss the security measures against bots, and provide a step-by-step guide on how to swiftly and effortlessly create and deploy a form using @uninterrupted/serverless-plugin-webform.

Server-side vs. Serverless

Server-side and serverless computing are two different approaches to building and running applications. With server-side computing, the developer is responsible for provisioning and managing servers, while with serverless computing it is handled by the cloud provider. Server-side computing is more traditional, while serverless computing is a newer approach that is gaining popularity.

The Old Fellow: Server-side Deployment

Server-side deployment is the old fellow of deploying web forms. In this approach, the server shoulders all the logic related to the form. It's a bit like being a one-man band. It can be a time-consuming and costly endeavor. In the traditional server-side approach, web forms rely on a dedicated server to handle form submissions. This involves setting up and maintaining server infrastructure, managing databases, and handling user requests/form submissions. While this method has been the norm for years, it comes with several challenges:

1. Scalability and Cost: Scaling server resources to accommodate varying traffic levels can be complex and costly. Over-provisioning leads to unnecessary expenses, while under-provisioning results in performance issues.
2. Maintenance: Traditional server setups demand continuous maintenance, including security updates, database management, and server monitoring. This can be time-consuming and require technical expertise.
3. Complex Deployment: Deploying updates to forms or making changes often involves multiple steps, increasing the chances of errors or downtime.

The New Kid on the Block: Serverless Deployment

Enter serverless deployment, the new kid on the block. This modern approach takes the server management load off your shoulders. It allows you, the developer, to focus on your code, while the infrastructure is handled by the serverless provider. The result? Faster deployment, lower costs, and improved scalability. The serverless approach revolutionizes form deployment by eliminating the need for dedicated servers. It leverages cloud services to handle form submissions dynamically, scaling automatically based on demand. Key benefits include:

1. Auto-scaling: Serverless platforms like AWS Lambda or Azure Functions automatically scale resources based on traffic, ensuring optimal performance without manual intervention.
2. Cost Efficiency: With serverless, you pay only for the actual usage, making it more cost-effective as you're not charged for idle resources.
3. Simplified Deployment: Serverless frameworks provide streamlined deployment pipelines, enabling quick updates and reducing the risk of deployment errors.
4. Faster Development: By abstracting server management, developers can focus on building the form's functionality rather than dealing with infrastructure.

Securing the Digital Neighbourhood

Much like a safe and secure neighborhood, our web forms too require protection from lurking threats, often manifesting as relentless bots. In the realm of web forms, security stands as the guardian defending the estate against thieves use the watchful eye of the honeypot and the housing estate barrier of reCaptcha.

The Watchful Eye - Honeypot

Imagine strolling down your friendly neighborhood street, where houses are welcoming and familiar. Among them, a house stands with an unseen, yet effective, guardian – a concealed pitfall that only trespassers unwittingly fall into. Similarly, a web form armed with a honeypot possesses an invisible field, lying in wait for bots that blindly wander through. While legitimate visitors tread without concern, bots stumble into this trap, instantly revealing their true identity. This quiet sentinel may not deter all invaders, but it thwarts those who are less cunning, keeping the virtual streets cleaner and safer. The honeypot technique is a cybersecurity strategy designed to detect, deflect, or study unauthorized access or malicious activity within a controlled environment. It involves setting up decoy systems, services, or resources that appear to be legitimate targets for attackers but are isolated from the main network infrastructure. The primary purpose of a honeypot is to gather valuable information about the tactics, techniques, and procedures (TTPs) employed by cybercriminals, thereby enhancing an organization's ability to defend against real-world threats.

Honeypots can be categorized into different types based on their goals and deployment:

1. Production Honeypots: These are designed to appear as normal systems or services within the organization's network. The intention is to observe and divert attackers from real assets while gathering information on their activities.

2. Research Honeypots: These are more elaborate and specialized systems that focus on in-depth analysis of an attacker's behavior. They often capture detailed information about the attack methods, such as the malware used, command and control traffic, and exploitation techniques.

3. High-Interaction Honeypots: These mimic actual systems and services to a high degree, providing attackers with a realistic environment. While they offer detailed insights, they are also more resource-intensive to maintain and require careful isolation to prevent unauthorized access to the main network.

4. Low-Interaction Honeypots: These are simpler decoy systems that emulate only a limited set of services, reducing the risk of an attacker gaining full access. They are easier to manage and deploy, but may not provide as much detailed information about attacker behavior.

Benefits of using the honeypot technique include:

1. Early Threat Detection: Honeypots can detect attacks that go unnoticed by traditional security measures. By attracting and engaging potential attackers, organizations can identify new attack vectors or vulnerabilities.

2. Behavioral Analysis: Detailed logs and data collected from honeypots can be analyzed to understand attackers' methods, tools, and motives. This information helps organizations improve their cybersecurity strategies.

3. Reduced False Positives: Since honeypots are isolated from critical infrastructure, any activity detected within them is highly likely to be malicious, reducing false positive alerts.

4. Experiential Learning: Cybersecurity professionals can gain hands-on experience with real-world attack scenarios in a controlled environment, enhancing their skills and understanding of threats.

In conclusion, the honeypot technique is a valuable tool in the cybersecurity arsenal, providing organizations with insights into emerging threats and attackers' methods. However, its implementation requires careful planning, management, and consideration of potential risks to ensure its effectiveness in enhancing overall security posture.

The Robust Barrier - reCaptcha

Picture your neighborhood equipped with an advanced security gate, challenging those who seek entry. This gate, known as reCaptcha, tasks newcomers with puzzles that distinguish between human interaction and automated trickery. Like a well-trained guard, reCaptcha vouches for genuine residents, while raising an alarm for suspicious characters. Whether it's a simple checkbox or a complex image recognition puzzle, reCaptcha adds an extra layer of protection to our digital community, deterring nefarious bots from entering our online neighborhood. reCAPTCHA, short for "Completely Automated Public Turing test to tell Computers and Humans Apart," is a widely used security technology developed by Google to distinguish between human users and automated bots on the internet. It was initially introduced as a way to prevent bots from abusing online services, such as submitting forms, creating accounts, or making purchases, while allowing legitimate human users to access these services without unnecessary friction.

The primary purpose of reCAPTCHA is to provide an additional layer of security to various online platforms by challenging users to prove their human identity through a series of tests that are easy for humans to solve but difficult for automated bots. Over the years, reCAPTCHA has evolved to include several versions, each designed to address different security and user experience needs.

Here are some key aspects of reCAPTCHA:

1. CAPTCHA Challenges: reCAPTCHA typically presents users with challenges that require cognitive or perceptual skills that bots find difficult to replicate. These challenges have included identifying distorted text, selecting specific images from a grid, or simply checking a box to confirm their human status.

2. Types of reCAPTCHA:

   • reCAPTCHA v2 "I'm not a robot": This version introduced the checkbox-style CAPTCHA where users simply need to click on the checkbox to verify their humanity. It often relies on behavioral analysis to determine whether a user is human or not.
   • reCAPTCHA v2 "Invisible reCAPTCHA": This version is even less intrusive, as it runs in the background and only displays a CAPTCHA challenge if the system suspects the user might be a bot.
   • reCAPTCHA v3: This version focuses on passive user verification. It assigns a risk score to each user interaction, allowing site owners to take action based on the perceived risk level. It doesn't require any explicit user interaction.

3. Advanced Technology: Google uses a variety of technologies, including machine learning and advanced risk analysis, to continuously improve the accuracy of distinguishing humans from bots. These technologies help reduce the likelihood of false positives (incorrectly identifying humans as bots) and false negatives (failing to identify bots).

4. Integration: Website owners can integrate reCAPTCHA into their platforms by including Google's reCAPTCHA API in their code. Google provides detailed documentation on how to implement and customize reCAPTCHA to suit the website's needs.

5. User Experience Considerations: While reCAPTCHA serves as a security measure, it's important to consider user experience. Overly complex challenges can frustrate users and discourage them from using a website. Balancing security with a user-friendly interface is crucial.

6. Accessibility: Google has taken steps to make reCAPTCHA more accessible to users with disabilities. For example, audio challenges are provided for visually impaired users who may have difficulty with visual challenges.

In recent years, the evolution of reCAPTCHA has led to debates about its effectiveness, user privacy concerns, and the potential for unintended consequences. Some users find certain challenges, especially those involving image recognition, to be frustrating or time-consuming. Additionally, there are concerns about the amount of behavioral data that Google collects as users interact with reCAPTCHA challenges.

In conclusion, reCAPTCHA plays a significant role in safeguarding online platforms from automated bots and enhancing overall cybersecurity. However, its implementation should be balanced with user experience considerations and privacy concerns to ensure a seamless and secure online environment for both humans and legitimate users.

An Impenetrable Alliance

Much like a vigilant neighborhood combining security systems, the strategic union of honeypot and reCaptcha forms an impervious barrier against the dragon of bots. While the honeypot lures and traps the naive intruders, reCaptcha stands tall as the fortified castle gate, testing the mettle of even the craftiest foes. By employing both methods, we build a formidable defense, ensuring that our virtual streets remain safe for residents while deterring those who aim to exploit our online community.

In the ever-evolving landscape of the web, where bots prowl like shadowy figures, the harmonious coexistence of honeypot and reCaptcha serves as our armor. Just as a tight-knit neighborhood watches out for its own, these security measures safeguard our digital spaces, enabling seamless interactions for genuine users while safeguarding against the encroaching darkness of automated threats.

Thinking of modernizing existing architecture?

Regardless of the profile of the solution, the introduction of a microservices architecture may positively affect the efficiency of the solution. We are happy to provide consultation in this area.

Contact Us

The Neighborhood Builder: Streamlined Form Deployment with @uninterrupted/serverless-plugin-webform

@uninterrupted/serverless-plugin-webform plugin is your guide to easy and secure form deployment. Here's how it works:

Begin with installing the plugin. Run the following command in your terminal within your serverless project:

npm install --save-dev uninterrupted-tech/serverless-plugin-webform

You can also use other package managers such as yarn or pnpm.

yarn add --dev @uninterrupted/serverless-plugin-webform

pnpm add --save-dev @uninterrupted/serverless-plugin-webform

After that you have to add the plugin to your serverless.yaml file. To do this add the name of the plugin to the plugins array:

plugins:
	- @uninterrupted/serverless-plugin-webform

Configure the plugin according to your preferences. Add or extend the custom property in your serverless.yaml file by pluginWebform. Here we will place all configuration of the plugin.

custom:
  pluginWebform:

The plugin has been designed with the intention of automating the form deployment process as much as possible. However, there is one property that requires user input: the configuration for Amazon Simple Email Service.

Amazon Simple Email Service is responsible for sending email notifications when someone fill the form and for sending email confirmation to the visitor. Since the email notification feature is optional, the visitor email confirmation is not, and you have to fill in the configuration of the email address from which the emails will be sent.

To do this, add a new property to your configuration named ses which stands for Simple Email Service, and set the sourceAddress property.

custom:
  pluginWebform:
		ses:
			sourceAddress: hello@uninterrupted.tech

That is actually all that is required. You can deploy the service with the default configuration.

serverless deploy

As a result, you will receive an endpoint to Amazon API Gateway that will execute the lambda function.

Detailed configuration

However, as the creators, we want to make it as flexible and configurable as possible. So, let's dive a bit deeper. In the next section we will guide you through each part of plugin configuration.

Simple Email Service (SES)

As mentioned earlier, the ses section contains the configuration for Amazon Simple Email Service

ses:
  sourceAddress: source@address.com
  notificationAddresses:
    - notification@address.com
    - notification@address2.com
  visitorNotification:
    subject: "New message"
    text: ./templates/visitor-notification.txt
    html: ./templates/visitor-notification.html
  visitorConfirmation:
    subject: Hello {{ name }}!
    text: ./templates/visitor-confirmation.txt
    html: ./templates/visitor-confirmation.html
  visitorConfirmationWitMessage:
    subject: Hello {{ name }}!
    text: ./templates/visitor-confirmation-with-message.txt
    html: ./templates/visitor-confirmation-with-message.html

sourceAddress - email address from which the emails will be sent,

notificationAddresses - You can add as many notification addresses as you need. When the array will contain at least one element, the lambda function will send a notification about new visitor to the email address. We intended to provide a functionality to notify admins, form owners, and maintainers about new visitors. If you do not configure the visitor notification property, it will be disabled.

visitorNotification - the optional notification email template configuration property. If no value is provided, the lambda will use the default template. Otherwise, you must fill three fields to provide your own template:

• subject - contains a subject of the email. You can use replacement tags here, such as {{ name }}. The replacement tags are used to personalize the email by inserting dynamic content, such as the recipient's name, into the subject line. The plugin documentation will provide a list of all the available replacement tags.
• html - contains path from root directory to your .html template message. You can also use replacement tags here.
• text - contains path from root directory to your .txt template message. You can also use replacement tags here.

Note: The HTML file is used to define the visual appearance of the email. However, some email clients may not display HTML emails correctly. To ensure that all recipients can read your email, you should also define a plain text version.

visitorConfirmation - The template is optional and can be used to send a confirmation message to the visitor. The configuration is the same for both the HTML and text templates.

visitorConfirmationWithMessage - The template can be used to send a confirmation message with the message/description provided in the form. The lambda function will use this template if the ccMe property in the API request is set to true. The template is optional.

Properties/Honeypot technique

As explained, the honeypot technique is a way to protect your forms from spam bots. Bots will usually fill out all of the fields searching for a common patterns. This way, you can identify spam bots and block them from submitting your form.

To use the honeypot technique, you need to configure the properties property in a configuration. This property is a mapping between a property and its value. The name property is an alias of the real field. As an example instead of email: hello@uninterrupted.tech we will send ssadads: hello@uninterrupted.tech.

properties:
  email:
    name: ssadads
  name:
    name: wmhhgio
  phoneNumber:
    name: idocynv
  description:
    name: xhqpdaf

Configuration allows to configure four properties:

• email,
• name,
• phoneNumber, and
• description.

The properties section is optional. If you do not provide any configuration, the honeypot technique will not be used.

reCAPTCHA

reCAPTCHA is a more advanced security mechanism that helps identify and block abusive traffic on a website. reCAPTCHA v3 does this without interrupting users with CAPTCHA challenges. Instead, reCAPTCHA v3 returns a score that you can use to decide how to handle each request. The reCAPTCHA configuration is quite simple and requires configuration of captcha property.

captcha:
  secret: secret
  threshold: 0.8

• secret - reCAPTCHA secret value,
• threshold - the score threshold. Requests with a score less than the threshold will be blocked and reported.

The captcha section is optional. If you do not fill it out, the CAPTCHA will be turned off. If you provide the secret property, the CAPTCHA will be enabled. However, it is important to never load the secret using an environment variable or put sensitive data directly in your code.

The default value for the threshold is 0.5. You can experiment with different values to find the best threshold for your needs. Here you can learn more about the score threshold and learn how to configure reCAPTCHA and generate secret.

Lambda function

This section covers the technical aspects of the configuration, specifically the Lambda function settings. While it is optional, you can modify the Lambda function name if you need to increase its resources or if the default name is already in use. The configuration is under the lambda property.

lambda:
  name: myLambda
  memorySize: 512

• name - the Lambda function name. Combined with the service and deployment stage name to form a unique identifier. The format is: ${serviceName}${stageName}${lambdaName}. The default value is createVisitor.
• memorySize - specifies the amount of memory and computing power allocated to the lambda function, measured in megabytes. The default value is 1024MB.

DynamoDB

DynamoDB is a fully managed, serverless, key-value NoSQL database. Here, we use it to store information about visitors and bots (e.g., data provided and reCAPTCHA details). Since two tables are required (one for visitors and one for bots), we have added the possibility to configure the names of the databases to prevent naming conflicts. The table name is a concatenation of the service and stage names, following the format: ${serviceName}${stageName}${tableName}, similarly to the Lambda naming convention applied previously. This configuration is located under the dynamoDb property and is entirely optional. When not provided, tables will be named using default values: visitors and bot-visitors.

dynamoDb:
  visitorsTableName: contacts
  botVisitorsTableName: bot-contacts

• visitorsTableName - property specifies the name of the table where comprehensive visitor information will be stored. The default value is visitors.
• botVisitorsTableName - property specifies the name of the table dedicated to storing data regarding bot visitors. The default value is bot-visitors.

Slack integration

Slack is a popular communication tool used by many organizations. We use it ourselves, and that's why we decided to add support for Slack notifications to our plugin. You can configure Slack notifications to be sent for new visitors. This is an optional feature, but the setup process is straightforward. The configuration for Slack is under the slack property.

slack:
  url: https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX
  channel: "#web-form-notifications"
  username: webhook-bot
  message: ./slack/message.txt
  iconEmoji: ":email:"

• url - Slack incoming webhook URL. Please refer to the instruction on how to generate the Slack incoming webhook URL,
• channel - name of an existing channel in your Slack organization where notifications will be sent,
• username - the username of the message sender,
• message - path from the root directory to your .txt template message. Within this file, you can define the appearance of your messages. Similar to the SES templates you can also use replacement tags here,
• iconEmoji - refers to the icon emoji of the channel. You can choose from a variety of emojis listed here. By default emoji is "📧" :email:.

Conclusion

In the ever-evolving landscape of web development, the deployment of web forms has transitioned from the traditional server-side approach to the modern serverless paradigm. This shift has brought about enhanced scalability, reduced costs, simplified deployment processes, and faster development cycles. To fortify the security of our digital neighborhoods against the onslaught of automated threats, the strategic alliance of honeypot and reCaptcha techniques provides a robust defense. In conclusion, the synergy between serverless deployment, honeypot and reCaptcha security techniques, and the @uninterrupted/serverless-plugin-webform plugin transforms the deployment and protection of web forms into a seamless and efficient process. By leveraging these tools, developers can enhance user experiences, bolster security measures, and contribute to the creation of a safer and more user-friendly digital environment.