End-of-Life (EoL)

API Protection

WAAS is able to enforce API security based on specifications provided in the form of Swagger or OpenAPI files. WAAS also allows for manual API definition. E.g. paths, allowed HTTP methods, parameter names, input types, value ranges, etc. Once defined, users can choose WAAS actions to apply for requests which do not comply with the API’s expected behavior.
Enforcement for body, header and formData parameters is currently not supported by WAAS.
Users should be careful when enabling Prisma Session Cookies along with API protection. Prisma Session Cookies mandates client’s support of cookies and javascript in order for them to reach the protected application. As APIs are often accessed by "primitive" automation clients, avoid enabling Prisma Session Cookies unless you are certain all clients accessing the protected API support BOTH cookies AND Javascript.

Importing API Definition From Swagger or OpenAPI

  1. Enter
    App Definiton
    Tab.
  2. Click on
    Import
    .
  3. Select definition file to load.
  4. Select
    API Protection
    Tab.
  5. Review path and parameter definitions listed under
    API Resources
    .
  6. Select
    Endpoint Setup
    Tab.
  7. Review protected endpoints listed under
    Protected Endpoints
    and verify configured base paths all end with a trailing *.
    Base path in the endpoint definition should always end with a * e.g. "/*", "/api/v2/*". If not configured that way, API protection will not apply to sub-paths defined in the API protection tab.
  8. Enter
    App Firewall
    Tab.
  9. Assign
    API Protection
    action for resources defined under
    API Resources
    tab and an action for all other paths.

Manual API Definition

  1. Enter
    App Definiton
    Tab.
  2. Select
    Endpoint Setup
    Tab.
  3. Add protected endpoints under
    Protected Endpoints
    and verify configured base paths all end with a trailing *.
    Base path in the endpoint definition should always end with a * e.g. "/*", "/api/v2/*". If not configured that way, API protection will not apply to sub-paths defined in the API protection tab.
  4. Select
    API Protection
    Tab.
  5. Click
    Add Path
  6. Enter
    Resource Path
    (e.g. /product - resource paths should not end with a trailing "/")
    Paths entered in this section are additional subpaths to the base path defined in the previous endpoint section. for example, if in the endpoint definition hostname was set to "www.example.com", base path set to "/api/v2/*" and in the
    API Protection
    tab resource path set to "/product" - full protected resource would be www.example.com/api/v2/product.
  7. Select allowed
    HTTP Methods
    .
  8. For each allowed HTTP method, define parameters by selecting the method from
    Parameters for
    dropdown list.
    1. Select HTTP method from dropdown list
    2. Click
      Add Parameter
    3. Enter parameter definition
  9. Enter
    App Firewall
    Tab.
  10. Assign
    API Protection
    action for resources defined under
    API Resources
    tab and an action for all other paths.

API Actions

HTTP requests that trigger API protections are subject to one of the following actions:
  • Alert
    - Request is passed to the protected application and an audit is generated for visibility.
  • Prevent
    - Request is denied from reaching the protected application, an audit is generated and WAAS responds with an HTML banner indicating the request was blocked.
  • Ban
    - Can be applied on either IP or Prisma Session IDs. All requests originating from the same IP/Prisma Session to the protected application are denied for the configured time period (default is 5 minutes) following the last detected attack. for more information on enabling Prisma Sessions and configuring ban definitions please refer to the Advanced Settings help page.
To enable ban by Prisma Session ID, Prisma Session Cookies has to be enabled in the Advanced Settings tab. for more information please refer to the Advanced Settings help page.
WAAS implements state, which is required for banning user sessions by IP address. Because Defenders do not share state, any application that is replicated across multiple nodes must enable IP address stickiness on the load balancer.

Recommended For You