API Discovery
Table of Contents
Self.Hosted 31.xx
Expand all | Collapse all
-
- Getting started
- System Requirements
- Cluster Context
-
- Prisma Cloud Container Images
- Kubernetes
- Deploy the Prisma Cloud Console on Amazon ECS
- Console on Fargate
- Onebox
- Alibaba Cloud Container Service for Kubernetes (ACK)
- Azure Container Service (ACS) with Kubernetes
- Azure Kubernetes Service (AKS)
- Amazon Elastic Kubernetes Service (EKS)
- IBM Kubernetes Service (IKS)
- OpenShift v4
-
- Defender Types
- Manage your Defenders
- Redeploy Defenders
- Uninstall Defenders
-
- Deploy Orchestrator Defenders on Amazon ECS
- Automatically Install Container Defender in a Cluster
- Deploy Prisma Cloud Defender from the GCP Marketplace
- Deploy Defenders as DaemonSets
- VMware Tanzu Application Service (TAS) Defender
- Deploy Defender on Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Autopilot
- Deploy Defender on OpenShift v4
-
- Agentless Scanning Modes
-
- Onboard AWS Accounts for Agentless Scanning
- Onboard Azure Accounts for Agentless Scanning
- Configure Agentless Scanning for Azure
- Onboard GCP Accounts for Agentless Scanning
- Configure Agentless Scanning for GCP
- Onboard Oracle Cloud Infrastructure (OCI) Accounts for Agentless Scanning
- Configure Agentless Scanning for Oracle Cloud Infrastructure (OCI)
- Agentless Scanning Results
-
- Rule ordering and pattern matching
- Backup and Restore
- Custom feeds
- Configuring Prisma Cloud proxy settings
- Prisma Cloud Compute certificates
- Configure scanning
- User certificate validity period
- Enable HTTP access to Console
- Set different paths for Defender and Console (with DaemonSets)
- Authenticate to Console with Certificates
- Configure custom certs from a predefined directory
- Customize terminal output
- Collections
- Tags
- Logon settings
- Reconfigure Prisma Cloud
- Subject Alternative Names
- WildFire Settings
- Log Scrubbing
- Clustered-DB
- Permissions by feature
-
- Logging into Prisma Cloud
- Integrating with an IdP
- Integrate with Active Directory
- Integrate with OpenLDAP
- Integrate Prisma Cloud with Open ID Connect
- Integrate with Okta via SAML 2.0 federation
- Integrate Google G Suite via SAML 2.0 federation
- Integrate with Azure Active Directory via SAML 2.0 federation
- Integrate with PingFederate via SAML 2.0 federation
- Integrate with Windows Server 2016 & 2012r2 Active Directory Federation Services (ADFS) via SAML 2.0 federation
- Integrate Prisma Cloud with GitHub
- Integrate Prisma Cloud with OpenShift
- Non-default UPN suffixes
- Compute user roles
- Assign roles
-
- Prisma Cloud Vulnerability Feed
- Scanning Procedure
- Vulnerability Management Policies
- Vulnerability Scan Reports
- Scan Images for Custom Vulnerabilities
- Base images
- Vulnerability Explorer
- CVSS scoring
- CVE Viewer
-
- Configure Registry Scans
- Scan Images in Alibaba Cloud Container Registry
- Scan Images in Amazon Elastic Container Registry (ECR)
- Scan images in Azure Container Registry (ACR)
- Scan Images in Docker Registry v2 (including Docker Hub)
- Scan Images in GitLab Container Registry
- Scan images in Google Artifact Registry
- Scan Images in Google Container Registry (GCR)
- Scan Images in Harbor Registry
- Scan Images in IBM Cloud Container Registry
- Scan Images in JFrog Artifactory Docker Registry
- Scan Images in Sonatype Nexus Registry
- Scan images in OpenShift integrated Docker registry
- Scan Images in CoreOS Quay Registry
- Trigger Registry Scans with Webhooks
- Configure VM image scanning
- Configure code repository scanning
- Malware scanning
- Windows container image scanning
- Serverless Functions Scanning
- VMware Tanzu Blobstore Scanning
- Scan App-Embedded workloads
- Troubleshoot Vulnerability Detection
-
- Compliance Explorer
- Enforce compliance checks
- CIS Benchmarks
- Prisma Cloud Labs compliance checks
- Serverless functions compliance checks
- Windows compliance checks
- DISA STIG compliance checks
- Custom compliance checks
- Trusted images
- Host scanning
- VM image scanning
- App-Embedded scanning
- Detect secrets
- OSS license management
-
- Alert Mechanism
- AWS Security Hub
- Cortex XDR alerts
- Cortex XSOAR alerts
- Email alerts
- Google Cloud Pub/Sub
- Google Cloud Security Command Center
- IBM Cloud Security Advisor
- JIRA Alerts
- PagerDuty alerts
- ServiceNow alerts for Security Incident Response
- ServiceNow alerts for Vulnerability Response
- Slack Alerts
- Splunk Alerts
- Webhook alerts
- API
API Discovery
WAAS can automatically learn the API endpoints in your app, show an endpoint usage report, and let you export all discovered endpoints as an OpenAPI 3.0 spec file.
When API discovery is enabled, the Defender inspects API traffic routed to the protected app.
Defenders learn the endpoints in your API by analyzing incoming requests and generating a tree of API paths.
Every 30 minutes, Defender sends the Console a diff of what it has learned since its last update.
The Console merges the update with what it already knows about the API.
The API discovery subsystem attempts to ignore all HTTP traffic that doesn’t resemble an API call.
The Defender uses some criteria for identifying which requests to inspect:
- Requests must have non-error response codes.
- Requests must not have extensions (like .css, and .html).
- Requests Content-Type must be textual (text/), application (application/), or empty.
On the API discovery database, when new path entries for images or API endpoints are added, the Console uses the 'Last Observed' date to delete the older entries to optimize the available resources.
When an image or API endpoint is deleted from the database, an alert is generated, and the details are written to the Console logs.
Enable API Discovery
API discovery is enabled by default when you create a WAAS policy.
To enable API discovery for a protected app after the rule is created:
- Log in to the Console, and go toDefend > WAAS > {Container (Inline/Out-Of-Band) | Host (Inline/Out-Of-Band) | App-Embedded | Serverless | Agentless}.
- Select an existing rule and enableAPI endpoint discovery.
Inspect discovered endpoints
The endpoint report under
Monitor
> WAAS
> API discovery
> enumerates discovered APIs per path, HTTP method, app, and on an image basis. It shows information such as Path, HTTP method, Hits, API protection status, Path risks, Workload that’s running these resources, Image Risk factors, Resource Vulnerabilities, App ID, and last seen date.
Path risks profiling
The
Path risks
indicate critical path risks identified in the endpoints:- Endpoints accessible from the internet.
- Endpoints that do not require authentication to be accessed.
- Endpoints with sensitive data such as Credit card, PII, ID query parameter, Session cookies, and so on. The sensitive data is defined underDefend > WAAS > Sensitive data.
- Endpoints with OWASP risks.
For example, some of the path risks detect the resource path with vulnerable API endpoints that are exposed to the internet, APIs with sensitive data, and APIs that allow unauthenticated access to them.
Select an endpoint to view the sidecar with additional statistics in the JSON structure, such as request and response size ranges, the sum of each specific returned status code, and the API change history.
The statistics also show the JSON payload that was sent with the API request.

API
Change History
logs detect changes in API observations such as authentication, query parameters, path risks, or any new sensitive data matches, but not changes to the body of API messages.
Under
Actions
, you can protect a path in an app, export the discovered endpoints for an app as an OpenAPI spec file, and also delete what WAAS has learned about the API for an app so far.If a rule with an app is deleted from the WAAS policy, its learned endpoints are also deleted.
Protecting endpoints
Select
Protect
next to a resource to protect a path, set effects for all API endpoints discovered in the App, and select Protect all
.
This enables you to protect all the API endpoints in the resource path identified within an app to the WAAS policy rule, not just the selected path.
When there is an event generated from a new endpoint, you have to explicitly Protect
it.
Export API specifications
Select
Export OpenAPI
next to the resource path to export all the API endpoints, HTTP method, and the Server name discovered by the app for the given WAAS policy rule as OpenAPI 3.0 JSON.
Limitations
- Click to Protect/Delete/Download openAPI actions apply to all paths in the app, and not possible to select individual paths.
- The amount of APIs that we can discover per image is limited to a size < 1k, and query parameters size is < 20k.
- Filtering/sorting the API discovery endpoints byAPI Protectionstatus is not applicable, as the protection status is calculated at the time of fetch (based on current policy).
Troubleshooting
- If a path is not learned on theAPI discoverypage, it could be because the endpoint is not a valid path (the endpoint didn’t return a status code of '200 OK'). The request had a WAF violation in it (The requests that trigger firewall rules are not learned).
- Public API flagged as an error. If the source IP of an endpoint does not belong to a known internet IP address, the API containing this endpoint is flagged as an error. This is because the IP addresses are stored in a static database, which could be outdated.
- Some of the endpoints are not flagged as unauthenticated. This is because for authentication we use a list of known headers and replies (401 response code) to learn, so if you are using some non-standard header for authentication, your endpoint will not be flagged.