Edgio
Edgio Console

Website Security through EdgeJS

Use CDN-as-code (EdgeJS) to apply basic security to your website.

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:
JavaScript./routes.js
1export default new Router().match({}, {
2    headers: {
3        set_response_headers: {
4            "Content-Security-Policy":
5            "default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi",
6        },
7    },
8});
To enable a content security policy in report-only mode:
JavaScript./routes.js
1export default new Router().match({}, {
2    headers: {
3        set_response_headers: {
4            "Content-Security-Policy-Report-Only": "default-src 'self'",
5        },
6    },
7});

TLS Version

We recommend that you enable TLS 1.3, 1.2, or both on your web server(s).
Key information:
  • A recommended best practice is to disable support for SSL/TLS versions 1.1 or older.
  • TLS 1.3 improves security and performance of internet communications. Specifically, it eliminates known TLS 1.2 security vulnerabilities and prevents snooping and man-in-the-middle attacks.

HTTP/1/2 Version

We support the following HTTP protocol versions for client requests to our network:
  • HTTP/1: Edgio uses the HTTP protocol version defined in the request when proxying requests to an origin and in the response provided to the client.
  • HTTP/2: Edgio uses the the HTTP/1.1 protocol when proxying requests to an origin and the HTTP/2 protocol for the response provided to the client.
Edgio also supports HTTP/3 for the communication between the client and the edge of our network, but it requires enablement. Contact your account manager or our sales department at 1 (866) 200 - 5463 to enable it on your account.

Secrets

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
  1. Navigate to the Environment Variables page.
    1. From the Edgio Console, select the desired private space or organization.
    2. Select the desired property.
    3. From the left-hand pane, select the desired environment from under the Environments section.
    4. From the left-hand pane, select Environment Variables.
  2. Click + Add Environment Variable.
  3. Set the Key option to the name of the desired environment variable. Use this name to reference the environment variable in your code.
  4. Set the Value option to the value that will replace references to this environment variable.
  5. If this environment variable contains sensitive information, mark the Keep this value a secret option.
  6. Click Add variable.
    Your new environment variable should now be listed.
    networking
Deploying to an environment using a deploy token pulls all environment variables and applies them to process.env. This allows these variables to be accessed at build time.
Deploying with a deploy token example: edgio deploy my-organization --environment=production --token=(my token)
Use environment variables to store all of your build and runtime secrets in a single place, Edgio 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.
Guard against this type of attack by ensuring that all request parameters that influence content rendering are included within your cache key.
For example, if you are rendering content based on a custom language cookie, then you must include it in your custom cache key:
JavaScript./routes.js
1export default new Router().match("/language/specific/:path", {
2    caching: {
3        cache_key_rewrite: {
4            source: "/language/specific/(.*)",
5            destination: "/language/specific/$1-%{cookie_language}",
6        },
7    },
8});