Firewall Concepts

To safeguard your application against malicious activity, Vercel's platform-wide firewall is the first line of defense, inspecting requests as they arrive at Vercel's Edge Network. Once a request passes this layer, deployment protection checks whether it can continue based on access rules set at the level of your project.

If allowed to go through, the request is subject to the rules that you configured with the Web Application Firewall (WAF) at the level of your project. If the request is not blocked by the WAF rules, your deployment can process and serve it.

If you enabled a persistent action for a WAF rule and it blocks the request, the source IP address is stored in the platform firewall so that future requests from this source continue to be blocked for the specified time period. These future blocks happen at the level of the platform-wide firewall.

The Vercel Firewall allows several possible actions to be taken when traffic matches a rule. These actions, that can be taken by custom rules or system DDoS mitigations, apply when detecting malicious traffic. You can view the actions and their results in the Firewall and Monitoring tabs.

The log action allows you to monitor and record specific traffic patterns without affecting the request. When a request matches a rule with the log action:

• The request is allowed to proceed normally.
• Details about the request are logged and displayed in the Firewall and Monitoring tabs, and sent to log drains for analysis.
• There is no impact on the visitor's experience.

This is useful for monitoring suspicious patterns or gathering data about specific types of traffic before implementing stricter actions.

The deny action blocks requests immediately when they match a rule. When a request is denied:

• A 403 Forbidden response is returned.
• The request does not reach your application.
• Usage is incurred only for the edge request and ingress Fast Data Transfer which are required to process the custom rule.

This is the most restrictive action and you should use it for known malicious traffic patterns or IP addresses.

A security challenge verifies that incoming traffic originates from a real web browser with JavaScript capabilities. Only human visitors using a web browser can pass the challenge and access protected resources, while non-browser clients (bots, scripts, etc.) cannot.

Use the challenge action when you want to block automated traffic while allowing legitimate users to access your content. It offers a middle ground between the log and deny actions, protecting against bots while maintaining accessibility for real visitors through a simple one-time verification.

When the challenge action is applied:

1. Initial challenge

   During this process, visitors see a Vercel Security Checkpoint screen:

   

   • The browser must execute JavaScript code to prove it's a real browser.
   • The code computes and submits a challenge solution.
   • The system validates browser characteristics to prevent automated tools from passing.
   • If the challenge succeeds, the WAF validates the request as a legitimate browser client and continues processing the request, which includes evaluating any additional WAF rules.
   • If the challenge fails, the request is blocked before reaching your application.

   The checkpoint page localizes to a language based on the visitor's browser settings and respects their preferred color scheme, ensuring a seamless experience for legitimate users.

2. Challenge session

   • Upon successful verification, a challenge session is created in the browser.
   • Sessions are valid for 1 hour.
   • All subsequent requests within the session are allowed.
   • Challenge sessions are tied to the browser that completed the challenge, ensuring secure session management.
   • After session expiration, the client must re-solve the challenge.

If your application makes additional requests (e.g., API calls) during a valid session, they automatically succeed. This is particularly useful for server-side rendered applications where the server makes additional requests to APIs in the same application.

• API routes that are protected by a challenge rule can only be accessed within a valid challenge session.
• Direct API calls (e.g., from scripts, cURL, or Postman) will fail if they require challenge validation.
• Direct API calls from outside a valid challenge session will not succeed.
• If a user hasn't completed a challenge session through your website first, they cannot access challenged API routes.
• Automated tools and scripts cannot establish challenge sessions. For legitimate automation needs, use Bypass to allow specific trusted sources.

The bypass action allows specific traffic to skip any subsequent firewall rules. When a request matches a bypass rule:

• For custom rule bypasses, the request is allowed through any custom or managed rules.
• For system bypasses, the request is allowed through any system-level mitigations.
• The request proceeds directly to your application.

This is useful for trusted traffic sources, internal tools, or critical services that should never be blocked.

A Denial of Service (DoS) attack happens when one device attempts to exhaust the resources of a system using methods such as sending a large amount of data to a server or network. These attacks can often be mitigated by finding and closing off the connection to the source of the attack.

A Distributed Denial of Service (DDoS) attack happens when multiple connected devices are used to simultaneously overwhelm a site with targeted, illegitimate traffic. The goal of DoS and DDoS attacks is to disrupt access to the servers hosting the site.

The OSI model is a concept that outlines the different communication steps of a networking system. Different attack types can target different layers of the OSI model.

DDoS attacks target either the network (layer 3), the transport (layer 4) or the application (layer 7) layer of the OSI model. Vercel mitigates against these attacks, and protects the entire platform and all customers from attacks that would otherwise affect reliability.

The goal of a layer 3 (L3) DDoS attack is to slow down and ultimately crash applications, servers, and entire networks. These attacks are often used to target specific IP addresses, but can also target entire networks.

The goal of a layer 4 (L4) DDoS attack is to crash and slow down applications. They target the 3-way-handshake used to establish a reliable connection between TCP connections. This is often called a SYN flood. Layer 4 DDoS attacks are used to target specific ports, but can also target entire protocols.

The goal of a Layer 7 (L7) DDoS attack is to crash and slow down software at the application layer by targeting protocols such as HTTP, which is often done with GET and POST requests. They are often silent and look to leverage vulnerabilities by sending many innocuous requests to a single page. Vercel provides sophisticated proprietary L7 mitigation and is constantly tuning and adjusting attack detection techniques.

Vercel Firewall leverages JA3 and JA4 TLS fingerprints to identify and restrict malicious traffic. TLS fingerprints allow the unique identification of user sessions inspecting details in the Transport Layer Security (TLS) protocol initiation process.

TLS fingerprinting is a process used to identify and categorize encrypted network traffic.

It creates a unique identifier from the details of a TLS client hello packet, such as the version of TLS, supported cipher suites, and included extensions.

• TLS fingerprints allow the unique identification of user session
• JA3 and JA4 transform the TLS handshake details into a hash
• The hash is used as a fingerprint to monitor and restrict access
• The hash can then be read from your Functions through the request headers

Controlling access by TLS fingerprint allows us to mitigate malicious actors that use sophisticated methods of attack. For example, a DDoS attack that is spread across multiple user agents, IPs, or geographic locations might share the same TLS fingerprint. With fingerprinting, the Vercel Firewall can block all of the traffic that matches that TLS fingerprint.

JA4 is part of the JA4+ suite. It offers a more granular and flexible approach to network fingerprinting, helping to mitigate malicious traffic and prevent bot traffic.

With JA4, it's possible to identify, track, and categorize server-side encrypted network traffic. This is crucial in detecting and mitigating potential security threats, as it provides a more comprehensive view of the network traffic when used in conjunction with other fields.

JA3 is a tool that uses TLS fingerprinting to track and identify potential security threats. It specifically focuses on the details of the TLS client hello packet, generating a unique hash from it. This client hello packet contains specific information such as the TLS version, supported cipher suites, and any extensions used.

In the Allowed Requests view of the Vercel WAF monitoring page, you can group the web traffic by JA4 Digest to review the fingerprints of the live traffic or the past 24 hours.

The following headers are sent to each deployment and can be used to process the request before sending back a response. These headers can be read from the Request object in your Function.

Unique client fingerprint hash generated by the JA4 algorithm. JA4 is preferred as it offers a more granular and flexible approach to network fingerprinting, which helps with mitigating malicious traffic.

Unique client fingerprint hash generated by the JA3 algorithm.