Edgio

API Security

Use API Security to:
  • Define valid payloads for API requests. Edgio categorizes a request as a threat when the payload violates at least one of your requirements.
  • Discover the APIs that have been requested in the last 30 days.
API Security requires activation. Contact your account manager or our sales department at 1 (866) 200 - 5463 to upgrade your account.

Setup

Set up an API Security configuration by performing the following steps:
  1. Create an API Security ruleset. An API Security ruleset consists of the following components:
    • API Security Rules: Define one or more API Security rules. Each of these configurations identifies an API schema and the conditions under which it will be enforced.
    • API Schema: An API schema is a JSON schema that describes the structure for a valid API payload.
    Setting up a new API Security rule requires creating at least one API schema. Your API Security rule will be read-only until you do so.
  2. Assign an API Security rule to a Security App configuration and define the enforcement action that will be applied to requests that violate the API schema(s) defined in the previous step.
By default, Edgio validates all POST, PUT, and PATCH requests that satisfy your security app’s hostname and URL path requirements. If your website uses those HTTP methods for non-API requests, then it is strongly recommended to define one or more URL path(s) within your API Security rule.

API Security Rule

An API Security rule identifies an API schema and the set of requests that must conform to that JSON schema. By default, your API Security rule validates all POST, PUT, and PATCH requests against an API schema. However, you may restrict inspection by:
  • Relative Path(s): You may restrict payload inspection to one or more relative path(s). This relative path starts directly after the hostname. The available comparison modes are listed below.
    • Default: Edgio Security will inspect all POST, PUT, and PATCH requests to ensure that they satisfy the API schema.
    • Exact match (multiple entries): Restrict inspection to specific relative path(s).
    • Wildcard match: Restrict inspection to a wildcard pattern for the relative path.
    • Regex match: Restrict inspection to a regular expression for the relative path.
      Wildcard and regular expression match comparison modes require Security Premier, Business, or Essentials. Contact your account manager or our sales department at 1 (866) 200 - 5463 to upgrade your account.
  • Method(s): You may restrict payload inspection to one or more of the following HTTP method(s): PUT | POST | PATCH

Exact Match (Multiple Entries)

Edgio Security compares the specified value(s) against the entire relative URL path. It will only inspect a request when one of the specified value(s) is an exact match. This comparison is case-sensitive.
Sample Configuration:
/cat
/bat
Matches:
/cat
/bat
Does Not Match:
/Cat
/Bat
/Category
/Moscato
/Batch

Wildcard Match

Edgio Security checks whether the entire relative URL path is a case-sensitive match for the wildcard pattern. The supported set of wildcards are listed below.
  • *: Matches zero or more characters.
    • Example: /cat*
    • Matches: /cat | /category
    • Does not match: /cAt | /Category | /muscat
  • ?: Matches a single character.
    • Example: /cat?
    • Matches: /cats
    • Does not match: /Cats | /cat | /muscats
  • [abc]: Matches a single character defined within the brackets.
    • Example: /[cm]art
    • Matches: /cart | /mart
    • Does not match: /tart | /start
  • [a-z]: Matches a single character from the specified range.
    • Example: /[a-z]art
    • Matches: /cart | /mart | /tart
    • Does not match: /Cart | /marT | /start
  • [!abc]: Matches a single character that is not defined within the brackets.
    • Example: /[!cm]art
    • Matches: /Cart | /Mart | /tart
    • Does not match: /cart | /mart | /tArt
  • [!a-z]: Matches a single character that is excluded from the specified range.
    • Example: /[!a-m]art
    • Matches: /Cart | /Mart | /tart
    • Does not match: /cart | /mart | /tArt
Example:
Setting the URL path(s) option to the following value allows Edgio Security to inspect any request whose URL path starts with /marketing/:
/marketing/*
The following sample request will match the above pattern:
https://cdn.example.com/marketing/mycampaign/image.png

Regex Match

Edgio Security checks whether the entire relative URL path is a match for the pattern defined in a regular expression.
Regular expressions are case-sensitive.
Sample Configuration:
^\/[a-zA-Z0-9]*$
Matches:
/cat
/CAT7
/Category
Does Not Match:
/Category 7
/Cat#7

API Schema

An API schema is a JSON schema that describes the structure for a valid API payload.
Define an API schema from within the Schemas tab of an API Security ruleset configuration. Use the Derive Schema from Example option to autogenerate a JSON schema from a sample JSON payload. You may then either build upon this base JSON schema to define a stricter set of requirements or save it without further modifications.

JSON Schema Syntax

The JSON Schema site provides guidance and examples on how to define a JSON schema. Edgio restricts syntax support as follows:
  • Edgio does not consider a number with a zero fractional part (e.g., 1.0, or 42.0) an integer.
  • Edgio ignores the $schema keyword.
  • Specify exclusiveMaximum and exclusiveMinimum as integers.
  • Remote schemas are unsupported.
  • String formats introduced after draft 4 are unsupported. For example, the following formats are unsupported: time | date | duration | idn-email
  • The following keywords are unsupported: $anchor | $comment | $dynamicAnchor | $dynamicRef | $recursiveRef |const | contentEncoding | contentMediaType| contentSchema | dependentRequired | if-then-else | minContains | maxContains | prefixItems | propertyNames | unevaluated
Use a JSON schema linter to fine - tune your API schema before applying it to your traffic.
For example, the JSON Schema Link site checks whether your JSON schema is valid and validates it against a sample API request.

JSON Schema Examples

A common method for setting up an API schema is to define the expected data type through the type property.
  • String Example: The following sample schema requires an API request to only contain a single string value:
    JSON
    1{
    2 "api_gw_id": "mnriXoB6",
    3 "type": "string"
    4}
  • Object Examples: The following sample schema requires an API request to contain an object. This object must contain a property called email set to a properly formatted email address:
    JSON
    1{
    2 "api_gw_id": "mnriXoB6",
    3 "type": "object",
    4 "properties": {
    5 "email": {
    6 "type": "string",
    7 "format": "email"
    8 }
    9 },
    10 "required": ["email"]
    11}
    The following sample schema requires an API request to contain an object. This object must contain a property called price set to a number greater than 0. If this object contains latitude, longitude, or id, then the validation defined for those properties will be enforced. For example, latitude may only be set to -90, 90, or any number in between that range.
    JSON
    1{
    2 "api_gw_id": "fg3r67doc1",
    3 "type": "object",
    4 "properties": {
    5 "latitude": {
    6 "type": "number",
    7 "minimum": -90,
    8 "maximum": 90
    9 },
    10 "longitude": {
    11 "type": "number",
    12 "minimum": -180,
    13 "maximum": 180
    14 },
    15 "id": {
    16 "type": "integer",
    17 "minimum": 0,
    18 "maximum": 999,
    19 "exclusiveMaximum": false
    20 },
    21 "price": {
    22 "type": "number",
    23 "minimum": 0,
    24 "exclusiveMinimum": true
    25 }
    26 },
    27 "required": ["price"]
    28}

API Security Ruleset Administration

You may create, modify, and delete API Security rulesets.
Key information:
  • Administer API Security rulesets from the API Security page.
  • Apply an API Security ruleset to production traffic by adding it to a Security App configuration and then determining how it will be enforced. Multiple Security App configurations may use the same API Security ruleset.
  • Setting up a new API Security rule requires creating at least one API schema within the current API Security ruleset. Your API Security rule will be read-only until you do so.
  • It may take up to 2 minutes for an update to an API Security ruleset to be applied across our entire network.
To create an API Security ruleset
  1. Navigate to the API Security page.
    1. From the Edgio Console, select the desired organization.
    2. From the Security section, click API Security.
  2. Click + Create New API Rule.
  3. In the Name of Ruleset option, type a name for this API Security ruleset.
  4. Click the Schemas tab. Edgio will save your configuration. You must save an API schema, as described in the next step, before setting up an API Security rule.
  5. Add a JSON schema that defines the structure for a valid API payload.
    1. Click + Create New and then click on the new API schema (i.e., Schema 1).
    2. In the Name option, type a name for this JSON schema.
    3. Perform one of the following steps:
      • Autogenerate Schema: Perform the following steps to automatically generate a JSON schema from a sample payload:
        1. Click Derive Schema from Example.
        2. Paste a sample JSON payload.
        3. Click Next >. Edgio will generate an API schema that describes the basic structure for your sample JSON payload.
        4. Optional. Enhance this API schema. For example, you may define a range of valid values for integer properties or you may define certain properties as required.
        5. When finished, click Apply.
      • Upload Schema: Upload an API schema by clicking Upload Schema JSON, selecting the desired file, and then clicking Open.
    4. Click Save Schema.
    5. Repeat steps 5.1 - 5.4 for each API schema that you would like to add to this API Security rule.
    You may apply different API schemas to different endpoints or operations by creating an API Security rule for each API schema. You should then restrict each API Security rule to only apply API schema validation to the desired set of endpoints or operations.
  6. Add an API Security rule that identifies the API schema created in the previous step and the set of requests to which it will be applied.
    1. Click the API GW Rules tab.
    2. Click + Create New.
    3. In the Name option, type a name for this API Security rule.
    4. Optional. Restrict the set of requests that will be inspected to one or more specific relative path(s).
      1. From the URL Path(s) option, determine whether Edgio will perform URL path comparisons by exact match, regular expression, or wildcards.
      2. Specify the desired relative path or regular expression.
        If you selected Exact Match, then you may specify multiple relative paths. Press ENTER after typing each desired URL path.
    5. Optional. Restrict the set of requests that will be inspected by HTTP method by selecting the desired HTTP method from the Methods option. Repeat this step as needed.
    6. From the Schema ID option, select the API schema created in step 5.
    7. Click Save.
To modify an API Security ruleset
  1. Navigate to the API Security page.
    1. From the Edgio Console, select the desired organization.
    2. From the Security section, click API Security.
  2. Click on the desired API Security ruleset.
  3. Make the desired changes.
  4. Click Save.
To delete an API Security ruleset
You cannot delete an API Security ruleset that is associated with a Security App configuration. Please either modify the Security App configuration to point to a different API Security ruleset or delete that Security App configuration.
  1. Check your Security App configurations to verify that the desired API Security ruleset is not in use.
  2. Navigate to the API Security page.
    1. From the Edgio Console, select the desired organization.
    2. From the Security section, click API Security.
  3. Click on the desired API Security ruleset.
  4. Click Delete.
  5. Click Confirm.

API Discovery

Edgio automatically discovers all API requests for the last 30 days.
Key information:
  • Expand an endpoint to break down request statistics by HTTP method and status code.
  • Request statistics are rounded to whole numbers. This may cause some entries to display 100% or 0% even though there are multiple entries for that endpoint.
  • Use this information to discover legacy or deprecated endpoints that are still being requested.

Version Control

Version control allows you to:
  • View a previous version of a configuration.
  • Reactivate a previous version of a configuration.
  • Compare a previous version of a configuration to the current version.
An advantage of using version control is that it allows you to quickly roll back to a previously vetted configuration. For example, if you notice that a new configuration has resulted in more false positives, then you can roll back to the previous version before analyzing the data.
To view, compare, and reactivate a previous configuration
  1. Load the desired security configuration (e.g., access rule, rate rule, or custom rule).
  2. Click Versions.
    Versions button
  3. Click on the desired version to view it.
    Version selection
  4. Optional. Compare the version selected in the previous step to the current version by clicking Diff. Differences between those two versions are highlighted in green (new or updated lines) and red (modified or deleted lines).
  5. Optional. Reactivate the version selected in step 3 by clicking Reactivate. Click Reactivate this version to confirm that it will be reactivated.