Configure Endpoint Discovery

Enable Seeker to discover all the declared and visited inbound endpoints in applications, such as APIs and application pages, to present a visual overview of their test coverage on the Endpoint Risk page.

  1. In the main menu, click (Projects) and open a project that you want to configure.
  2. Click Features.
  3. Toggle the Enabled switch for Endpoint Discovery on.
Note: You may want to disable this feature if it impacts the application's performance.

If the feature is enabled, you have the following configuration options:

Configure

Instruct Seeker to collect endpoints for your project.

  1. Click Configure.

    Choose the endpoint collection strategy:

    • Endpoints declared by application (default)

      Seeker collects all the endpoints that are declared in the code of your application. This is particularly useful for modern applications based on backend APIs and client-side routing, such as single-page applications.

    • Endpoints monitored by Agents

      Seeker collects all the endpoints monitored by Agents, such as APIs and application pages, which includes the declared endpoints. This is particularly useful for applications based on server-side routing and web pages, such as JSP applications.

    Endpoint coverage is calculated as a percentage of the tested endpoints in the overall number of collected endpoints.
  2. Save your changes.

Configure exclusion rules

Instruct Seeker to exclude certain endpoints from endpoint discovery by defining exclusion rules.

  1. Click Configure exclusion rules.
  2. Click + Add exclusion rule.
    To create an exclusion rule, select a part of HTTP request/response and define an exclusion pattern or value for this part.
    • For Response status code, enter a value.
    • For all parts except Response status code, enter a pattern.

      Note that patterns can include the asterisk (*) as a wild card and are matched exactly. For example, /my/webapp would be matched by /my*, but not by /my.

    Tip: Here are some request or response parts for which you might need exclusion rules:
    • Request path: to exclude certain paths in your application that might be irrelevant for your testing. For example, /admin_console/* path that belongs to the hosting platform.
    • Request parameter name or Request header name: to exclude requests that are auto-generated by other testing tools used together with Seeker.
    • Response content-type: to exclude certain types of responses from the application, such as responses with Content-Type: img/png, which might be irrelevant for your security testing.
    • Response status code: to exclude certain response codes, such as 500 indicating an application bug, which might be irrelevant for your security testing.
    • HTTP method: to exclude endpoints based only on the HTTP verb.
    • Request Path: to exclude endpoints based on the URL path. An HTTP verb can be used with the Request Path, but to use a verb alone, see HTTP Method.
      Note: Use a verb with Request Path when:
      • You don't want the exclusion to affect all the endpoints using the same HTTP method
      • You don't want it to affect all the operations that happen on the same URL path
      For example, you might want to exclude the OPTIONS method for the URL /api/foo/* but still test the GET and POST methods with the same URL. That pattern would look like the following: OPTIONS /api/foo/*
  3. Save your changes and click back to features.
    Note: Once you have saved a new or updated rule, it will take immediate effect, so the existing endpoints that match it will be removed from the current endpoint view. A confirmation prompt will appear when you click Save.
  4. You can edit or delete an existing rule by clicking the respective button in its row.

Configure API specification

Click Configure API specification.

  • Seeker automatically collects OpenAPI specifications exposed by your application at runtime to perform Active Inspection of the endpoints. Additionally, you can manually upload an API specification file for your application. This is helpful when no API specifications have been automatically collected or if you want Seeker to use another API specification.

    1. Click Upload under API specification file and upload your application's API specification file in JSON format, for example, swagger.json. If another file was uploaded previously, the new file will replace it.
    2. You can delete an uploaded file by clicking Delete.
  • Seeker parses API specifications to collect endpoints statically without application traffic. By doing this, it will detect any undocumented endpoints or parameters, a.k.a shadow APIs, which pose a high application security threat. The collected endpoints will be displayed on the Endpoint Risk page.

    By default, the Enable API specification parsing option is on.

    You can disable API specification parsing if you want Seeker to discover endpoints using runtime analysis only.
  • Optionally, enter a Base Path to determine the correct path for all endpoints found in the API specification. A base path (basePath OpenAPI field) is a prefix for all endpoint paths relative to the host root, such as /rest/api in https://www.example.com/rest/api/products.

Save your changes when done.