Security Suite


Edgio’s platform is built to ensure your website and applications remain open for business by keeping you protected against a wide range of security risks without sacrificing performance.
A fully PCI-compliant solution, Edgio Security protects your business against a variety of common exploits like SQL injections, cross-site scripting (XSS), PHP injections, bot attacks, DDoS attacks, and other common vulnerabilities.
This guide shows you how to keep your site and platform secure using Edgio.

DDoS (Distributed Denial of Service)

Edgio Enterprise customers enjoy always-on DDoS protection inside of our high-bandwidth, globally distributed network. Our solution offers basic protection against common layer 3 and 4 attacks in real-time so you never have to sacrifice performance for protection.

WAF (Web Application Firewall)

WAF Overview

WAF is a web application firewall that helps protect your web applications and APIs against common web exploits an attacker may use to compromise your security, overwhelm resources, and affect the availability of your application.
Utilizing the Edgio WAF allows you to monitor, filter, and block HTTP traffic against common vulnerabilities such as cross-site scripting (XSS) or SQL injection before they reach your origin.
The WAF includes Managed Rule Groups, managed by Edgio, that can be configured in either a flagging or blocking mode. You can enable all of the rules within these groups or configure each independent rule within the group based on your needs.

Managed Rule Groups

Edgio Managed Rules

​​The Edgio Managed rule group contains rules that are generally applicable to web applications. This provides protection against exploitation of a wide range of vulnerabilities, including high risk and commonly occurring vulnerabilities described in OWASP® publications such as OWASP Top 10.
Edgio recommends utilizing this rule group for all WAF use cases.
Edgio Managed Rule Group Descriptions

Admin Page Protection Rule

The Admin protection rule group contains rules that allow you to block external access to exposed administrative pages. This might be useful if you run third-party software or want to reduce the risk of a malicious actor gaining administrative access to your application.
Admin Page Protection Rule Description

Bad Input Rules

The Bad Input rule group contains rules to block request patterns that are known to be invalid and are associated with exploitation or the discovery of Common Vulnerabilities and Exposures (CVEs). This can help reduce the risk of a known malicious actor discovering a vulnerable application.
Edgio recommends enabling the ‘Bad Input - Log4J’ rule on all WAF applications.
Bad Input Rule Descriptions

PHP Application Rules

The PHP application rule group contains rules that block request patterns associated with the exploitation of vulnerabilities specific to the use of the PHP programming language. This includes the injection of unsafe PHP functions into requests.
PHP Application Rule Descriptions

SQL Database Rules

The SQL database rule group contains rules to block request patterns associated with exploitation of SQL databases, like SQL injection attacks. This can help prevent remote injection of unauthorized queries. Evaluate this rule group for use if your application interfaces with an SQL database.
SQL Database Rule Descriptions

Add Rule Groups to a WAF

Add Rule Groups to WAF
  1. Log in to the Edgio console.
  2. Click SECURITY from the top banner to launch the WAF Security Rules page.
  3. Select WAF-1 or WAF-2 from the first dropdown and the configuration version from the second.
  4. Click EDIT to set your security rules.
Add Rule Groups to WAF2
  1. Select the Set all rules to … dropdown. Hover over the dropdown for the rule group’s description.
  2. Choose the action for the group: Off, Flag, or Block.
  3. When you’ve made all your changes, click ACTIVATE. You will see a popup confirming your rule changes.
  4. Click ACTIVATE to confirm the rule changes or CANCEL to continue editing. When your changes have deployed, the version will update with the next incremental number.

Add Single Rules to a WAF

Add Single Rule to WAF
  1. Log in to the Edgio console.
  2. Click SECURITY from the top banner to launch the WAF Security Rules page.
  3. Select WAF-1 or WAF-2 from the first dropdown and the configuration version from the second.
  4. Click EDIT to set your security rules.
Add Single Rule to WAF2
  1. If collapsed, expand the Rule Group dropdown using the arrow to its left. You can hover over the rule name or the Flag/Block dropdown to view the rule’s description.
  2. Click the Flag/Block dropdown.
  3. Select the action for the rules you want to change: Off, Flag, or Block.
  4. When you’ve made all your changes, click ACTIVATE. You will see a popup confirming your rule changes.
  5. Click ACTIVATE to confirm the rule changes or CANCEL to continue editing. When your changes have deployed, the version will update with the next incremental number.

Apply a WAF to Your Environment

Prerequisite: Configured WAF rules and/or rule groups.
Once you’ve configured the WAF rules you want to use, you need to apply them to the corresponding environments you want to deploy them on. Rules are NOT applied to traffic until you take this step to apply them.
Follow these steps to add a WAF to an environment:
Apply WAF to Environment
  1. Log in to the Edgio console and select your site.
  2. Click the ENVIRONMENTS tab.
  3. Choose an environment from the list.
Security Configuration
  1. Select CONFIGURATION from the top navigation.
  2. Click EDIT.
  3. Scroll down to the Security section.
  4. From the dropdown, select an active WAF to add.
  5. Click the ACTIVATE button from either the top or the bottom of the page.

Bot Detection

Detect Bots with Managed Rules

The Edgio Bot protection contains rules to block and manage requests from bots. You are charged additional fees when you use this product.
The Bot Control product applies labels to a set of verifiable bots that are commonly allowed. The rule group doesn’t block this category of commonly allowed bots.
Bot Control Rule Group: In addition to the WAF rule groups, Edgio offers an additional Managed Rule Group for bots that allows you to take action against common bots that may impact the performance and availability of your web application or APIs.
You can monitor the impact of your bots by flagging each bot type of request gaining insights into SEO bots, scraping bots, advertising bots, malicious user agent bots, and several other categories of bots.
Bot Control Rule Descriptions

Detect Bots with EdgeJS

General Information

Edgio examines the user-agent header in an incoming request to determine if it includes a string that indicates if it is a bot, and if so, injects 1 in the x-0-device-is-bot request header, which will be visible to your server code. If the user-agent header does not include any of the strings indicating a bot, a 0 value is injected.

User Agents and Bots

The following table list the user agents that Edgio examines and describes the corresponding bots.
User AgentBot Description
embedlyEmbed.ly web crawler bot that performs HTTP requests most often in automatic mode.
facebookexternalhitFacebook bot that crawls the HTML of social plugins, apps, and websites shared on Facebook. The bot gathers and caches data (title, description, thumbnail image) about the shared content and presents the data as a preview.
flipboardFlipboard Proxy Service bot that runs in response to a user request for the service to scan a social media feed such as Twitter, and construct a processed feed of items to deliver in real time.
googlepagesspeedGoogle bot that assists in ranking search results based on page load speed.
Google web/snippetGoogle+ Enterprise bot that extracts high-level data from a URL posted on Google+ Enterprise and presents the data as a snippet of the URL.
headlessBots, usually scripts, that run on a scheduled basis or are triggered from an external system. Headless bots usually perform activities like sending alerts or daily digest messages. The scripts usually run for a short time, then terminate.
ia_archiverAmazon Alexa bot that crawls web sites for issues related to Amazon’s Site Audit service.
outbrainOutbrain Recommendation Platform chat bot.
pinterestAutomated Pinterest bot that creates boards and schedules pins to post to customer accounts.
prerenderPrerender.io hosted service bot that produces an easily crawled version of dynamically rendered pages, allowing indexing by search engines.
previewYahoo bot that extracts data (title, description, thumbnail images) from a URL embedded in an email and presents the data as a preview of the URL
qwantifyWeb crawler bot that indexes content for the Qwant search engine.
scannerBots that analyze how well your website and its security measures respond to various bot threats.
slurpYahoo Search bot for crawling and indexing web page information.
spiderGeneral purpose automated bots that crawl the web to index web page information.
tumblrTumblr bot that performs automated HTTP requests as a web crawler.
vkshareVK social network bot that performs automated HTTP requests usually as a web crawler.
w3c_validatorW3C bot that checks Web documents in formats like HTML and XHTML for conformance to W3C Recommendations and other standards.
whatsappWhatsapp platform chat bot.
xing-contenttabreceiverXing social network crawler bot that indexes content for the Xing social network.
yahooAnother Yahoo Search robot for crawling and indexing web page information.
If the set of bots detected by Edgio is not sufficient for your needs, you can easily add your own bot detection through EdgeJS and its match and setRequestHeader APIs:
2 {
3 headers: {
4 'user-agent': /^regex-for-your-bot-detection$/i,
5 },
6 },
7 ({ setRequestHeader }) => {
8 setRequestHeader('my-bot-detection-is-bot', '1')
9 },
11// ... all your other routes go here and they can match on `my-bot-detection-is-bot: 1`
The above code will match all the routes that even have a user-agent header and then inject the my-bot-detection-is-bot when the value of the user agent header matches the given regex. Once the header has been injected, the later routes can test for it and implement bot handling. Or, you could just let the header be sent upstream for your backend to handle it.

Security Reporting

  1. Log in to the Edgio console and select your site.
  2. Click the ENVIRONMENTS tab.
  3. Choose an environment.
  4. Click the SECURITY tab from the top page navigation.

Security Activity

WAF Activity
View OptionAccess
a.Deployment numberToggle on/off via WAF Activity settings.
b.Number of requests by action (passed, flagged, blocked)Hover over graph data.
c.Requests by action (passed, flagged, blocked)Toggle the checkboxes.
d.Deployments and/or full cache flushesToggle on/off via WAF Activity settings.

Rules Applied

Rules Applied
View OptionAccess
a.Date rangeSelect 24 hour, 7 days, or 28 days.
b.Flagged and/or Blocked requestsToggle the Flagged and Blocked buttons.
c.Graph of rules appliedClick inside the graph to list the names of the rules that have been applied to your Bot Control or Edgio Managed rules. Click Back to Rule Sets to return to the previous view.

Rules Section

View OptionAccess
a.Rules by typeExpand or collapse the list using the arrow to the left of the rule type.
b.Route detailsClick the rule name to view route information for that rule, including its path and number/percentage of total, flagged, and blocked requests.


Here is a sample log file highlighting the WAF data (“waf”:“botLib,flagged”,“wafv”:“WAF-1,2”): the action applied, the mode, the WAF name, and the version number, respectively.
WAF Log File Example

Website Security with EdgeJS

Content Security Policy (CSP)

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to distribution of malware.
You can easily add CSP headers to your site via a catch-all route near the top of your router.
To enforce a content security policy:
1new Router().match('/:path*', ({ setResponseHeader }) => {
2 setResponseHeader(
3 'Content-Security-Policy',
4 "default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi",
5 )
7// The rest of your router...
To enable a content security policy in report-only mode:
1new Router().match('/:path*', ({ setResponseHeader }) => {
2 setResponseHeader('Content-Security-Policy-Report-Only', "default-src 'self'")
4// The rest of your router...

Enabling Basic Authentication

You can add basic authentication to your site using the requireBasicAuth router method. For example, add the following to the top of your router:
2 username: process.env.BASIC_AUTH_USERNAME,
3 password: process.env.BASIC_AUTH_PASSWORD,
Then, add BASIC_AUTH_USERNAME and BASIC_AUTH_PASSWORD environment variables to each environment that should enforce basic authentication. Any environment without those environment variables will not enforce basic authentication.
Once deployed, the router will return 403 Forbidden for requests that have the incorrect basic authentication token, and 401 Unauthorized for requests that have no basic authentication token.


By default Edgio only serves traffic over the https protocol. It automatically redirects http requests to the same URL, including any query strings, on https.
We strongly discourage the use of http protocol, but if you must enable it, then you can do so by adding protocol: 'http' to your route criteria. For example:
1// routes.js
3// Respond to Let's Encrypt HTTP-01 challenge.
5 {
6 protocol: 'http',
7 path: '/.well-known/acme-challenge/<your token>',
8 },
9 ({ send }) => {
10 send('<token value>')
11 },
If you want the route to match both http and https protocols you can match on protocol: /^https?$/. If no route is matched on http protocol then Edgio will fallback on its default behavior of automatically redirecting the request to https.
  • A request’s protocol can be determined by reading the x-0-protocol request header or the request.secure property.
  • During local development all requests will appear secure by default. To test your router for http protocol matching you must either set the local_layer0_emulate_http_protocol cookie to true (if using a browser) or send an x-0-protocol request header set to http.

HTTP/1/2 Version

The incoming HTTP version is independent of the upstream HTTP version. We support HTTP/1 or HTTP/2 on ingress requests. We prioritize HTTP/2 to origin servers. If the origin server does not support the incoming HTTP version (say version HTTP/2 came in but origin only supports HTTP/1), we will downgrade to successfully complete the request, but the outgoing response will return to HTTP/2.


Rather than putting secret values such as API keys in your code and checking them into source control, you can securely store them in environment variables, then access them in your code from process.env. To configure environment variables, navigate to your environment, click EDIT, then under Environment Variables, click ADD VARIABLE.
As of Edgio CLI version 2.19.0, when you deploy to an environment using a deploy token, for example by running 0 deploy my-team --environment=production --token=(my token) option, all environment variables are pulled down from the Edgio Developer Console and applied to process.env so they can be accessed at build time. This allows you to store all of your build and runtime secrets in a single place, Edgio Developer Console, rather than storing some in your CI system’s secret manager.

Cache Poisoning

Cache poisoning attack is described by OWASP® as:
The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue to receive the malicious content until the cache entry is purged.
To guard against this attack you must ensure that all the request parameters that influence the rendering of the content are part of your custom cache key. Edgio will automatically include the host header and URL. Including other request headers and cookies are your responsibility.
For example, if you are rendering content based on a custom language cookie, then you must include it in your custom cache key:
1import { CustomCacheKey } from '@layer0/core/router'
3router.get('/some/path/depending/on/language/cookie', ({ cache }) => {
4 cache({
5 key: new CustomCacheKey().addCookie('language'),
6 // Other options...
7 })


What’s the difference between WAF-1 and WAF-2?

You can configure 2 different WAF instances, allowing you to apply different sets of security rules to different environments.

How do I know which version to use?

Like all Edgio products, WAF gives you access to all previous and active versions of your configuration so you have historical setups in case you need to roll back the current version.While editing, the version is in a Draft state; once activated, the version is Active.

What is the difference between flagging and blocking a rule or rule group?

To flag a rule or rule group means to mark it if the rule would have been activated without actually denying the traffic. In contrast, when you block a rule or rule group, traffic is denied on affected routes. You can view both flagged and blocked data in your Edgio console.

What are Edgio Managed Rules and why should I apply this rule group?

Managed rules block specific known threats. Edgio recommends this rule group for all WAF use cases.
Note: Edgio recommends that all customers activate the Bad Input - Log4J rule group.

Is the Edgio WAF a PCI-compliant solution?

Yes. Edgio maintains PCI-DSS Level 1 compliance by undergoing annual audits from approved Visa and MasterCard auditors.

What is the minimum level of encryption for Edgio?

Edgio enforces a minimum version of TLS 1.2 or higher.