Bot Protection
Table of Contents
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
Bot Protection
WAAS bot protection provides visibility into bots and other automation frameworks accessing protected web applications and APIs.

Bot Categories
WAAS detects known good bots as well as other bots, headless browsers, and automation frameworks. WAAS is also able to fend off cookie-dropping clients and other primitive clients by mandating the use of cookies and javascript in order for the client to reach the protected origin.
Bots are categorized into the following Categories:
- Search Engine Crawlers- Bots systematically crawling and indexing the World Wide Web to index pages for online searching. Also known as spider bots or web crawlers.
- Business Analytics Bots- Bots that crawl, extract, and index business related information.
- Educational Bots- Bots that crawl, extract and index information for educational purposes, such as academic search engines.
- News Bots- Bots that crawl, extract and index the latest news articles, usually for news aggregation services.
- Financial Bots- Bots that crawl, extract and index financial related data.
- Content Feed Clients- Automated tools, services or end-user clients that fetch web contents for feed readers.
- Archiving Bots- Bots that crawl, extract, and archive website information.
- Career Search Bots- Automated tools or online services that extract and index job-related postings.
- Media Search Bots- Bots that crawl, extract and index media contents for search engine purposes.
This category contains various bots and other automation frameworks which cannot be classified by their activity or origin
- Generic Bots- Clients with attributes that indicate an automated bot.
- Web Automation Tools- Scriptable headless web browsers and similar web automation tools.
- Web Scrapers- Automated tools or services that scrape website contents.
- API Libraries- Software code libraries for Web API communications.
- HTTP Libraries- Software code libraries for HTTP transactions.
- Request Anomalies- HTTP requests with anomalies that are not expected from common web browsers.
- Bot Impersonators- Bots and automation tools impersonating as known good bots to evade rate limitation and other restrictions.
- Browser Impersonators- Automated tools or services that impersonate common web browser software.
Users can create custom signatures to be used based on HTTP headers and source IPs.
User-defined signatures are useful for tracking customer specific bots, self-developed automation clients and traffic that appears suspicious.
Detection methods
WAAS uses static and active methods for detecting bots.
Static detection examines each incoming HTTP request and analyzes it to determine whether it was sent by a bot.
Active detections make use of javascript and Prisma Sessions Cookies to detect and classify bots.
When enabled, WAAS will set a Prisma Session cookie in each client.
Prisma Session Cookies set by WAAS are encrypted and signed to prevent cookie tampering. In addition, cookies include advanced protections against cookie replay attacks where cookies are harvested and re-used in other clients.
Prisma sessions are intended to address the problem of "Cookie Droppers" by validating clients support of cookies and Javascript before allowing them to reach the origin server. Once enabled, WAAS serves an interstitial page for any request that does not include a valid Prisma Session Cookie. The interstitial page sets a cookie and redirects the client to the requested page using Javascript. A client that doesn’t support cookies and Javascript will keep receiving the interstitial page. Browsers can easily proceed to the requested page, and once they possess a valid cookie they will not encounter the interstitial page.
In addition to Prisma Sessions Cookies, active detections also include javascript-based detections.
When enabled, javascript will be injected periodically in server responses to collect browser attributes and flag anomalies typical to various bot frameworks. Javascript fingerprint results are received and processed asynchronously and are used to classify session for future requests.
Detection workflow

Deploying Bot Protection
Known bots
- Go toBot protection > Known bots.
- Choose actions for each bot category.
Unknown bots
- Go toBot protection > Unknown bots.
- Choose actions for each bot category.
- If Request anomalies are enabled, choose sensitivity threshold
- Strict enforcement- high sensitivity (a few anomalies suffice for classifying as bot).
- Moderate enforcement- medium sensitivity.
- Lax enforcement- low sensitivity.
User-defined bots
- Go toBot protection > User defined bots.
- SelectDefine new bot.
- Create bot signature by using a combination of the following fields:
- HTTP Header name- specify HTTP header name to include in the signature
- Header Values- comma-separated list of values to be matched on in the HTTP header. Wildcard is allowed.
- Inbound IP sources- specify Network list of IP addresses from which the bot originates.
- Choose an action to apply.
Enabling active detections
- Go toBot protection > Active bot detection.Active Bot detection requires Prisma Sessions Cookies to be enabled in the advanced settings tab.
- Choose actions to apply.
- Session Validation- action to apply when WAAS is unable to validate the session, either due to cookie tampering or cookie replay.
- Javascript-based detection- enable periodic injection of javascript to collect browser attributes and flag anomalies typical to various bot frameworks.
- Javascript injection timeout- once javascript is enabled, choose action to apply when the browser does not send a response to the javascript injection on time.
- reCAPTCHA v2 integration- enable Google’s reCAPTCHA v2 integration by specifying the site key, secret key and challenge type. For more details please refer to the elaborated section on reCAPTCHA below.
reCAPTCHA v2 integration
WAAS Users can enable Google’s reCAPTCHA v2 integration by specifying the site key, secret key and challenge type.
According to the user’s preference and settings, WAAS will serve a reCAPTCHA challenge at the beginning of each new session, or when a request is suspected of being sent by an unknown bot.
Only reCAPTCHA v2 is supported.
Deploy reCAPTCHA
Deploy reCAPTCHA.
- Enter theSite keyprovided during the site registration
- Enter theSecret keyprovided during the site registration
- Select theChallenge typespecified during the site registrationChallenge type MUST match the challenge type selected on the reCAPTCHA site registration form (invisible or checkbox) for the reCAPTCHA integration to function properly.WAAS reCAPTCHA v2 integration does not support "reCAPTCHA Android" type
- Choose a preferredfriction.reCAPTCHA will ONLY be served for GET HTTP requests. WAAS will block requests sent using other methods until a reCAPTCHA challenge is solved and the success result is encoded into the Prisma Session Cookie.
- By policy (reCAPTCHA as an action)- when selected, a new effect will be available in the Unknown bot categoryWhen the reCAPTCHA is selected, WAAS will serve an interstitial page with a reCAPTCHA challenge whenever the protection is triggered.If the end-user successfully passes the challenge, it will be recorded in the Prisma Session Cookie for the duration of the Success Expiration setting (default is 24 hours).
- Each new session- Every new session will start with an interstitial page containing the reCAPTCHA challenge. If the end-user successfully passes the challenge, it will be recorded in the Prisma Session Cookie for the duration of the Success Expiration setting (default is 24 hours).
- Set theSuccess Expiration(in hours).This field determines how long a successful solution to a reCAPTCHA challenge will remain valid. Once the expiration date has passed, a new reCAPTCHA challenge will be presented (based on the selected friction settings).
- EnableCustom reCAPTCHA pageoption to enter a customized HTML reCAPTCHA. The minimum required defender version is v30.00.
Bot protection events
- Known bots- if a known bot is detected, the event message and attack type will provide details regarding the bot classification.
- Unknown bots- if an unknown bot is detected, the event message and attack type would provide details regarding the bot classification
- User-defined bots- a used-defined bot has been detected.
- Session Validation- The web client failed to pass the bot-detection session validation checks (e.g. prisma session cookie has been tampered with etc.).
- Javascript Injection Timeout- the web client failed to pass the bot-detection JavaScript injection check in reasonable time (timeout).
- Missing Cookie- client made a non GET request without a cookie.
- Failed reCAPTCHA verification: <error returned from Google verification API>- Google’s reCAPTCHA verification API has responded with an error message.
- <HTTP method> request when a reCAPTCHA page is required- As mentioned in the reCAPTCHA v2 integration section, reCAPTCHA will ONLY be served for GET HTTP requests. WAAS will block requests sent using other methods until a reCAPTCHA challenge is solved and an event carrying this message will be registered.
Bot Protection Actions
Requests that trigger a WAAS bot protection are subject to one of the following actions:
- Alert- The request is passed to the protected application and an audit is generated for visibility.
- Prevent- The request is denied from reaching the protected application, an audit is generated and WAAS responds with an HTML page 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.
- Allow (available for user-defined bots)- request is forwarded to the protected application and no audit is generated.
- reCAPTCHA- a page will be served with a reCAPTCHA v2 challenge to be solved before proceeding to the website.
A message at the top of the page indicates the entity by which the ban will be applied (IP or Prisma Session ID). When the X-Forwarded-For HTTP header is included in the request headers, ban will apply based on the first IP listed in the header value (true client IP).
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 or Prisma Sessions.
Because Defenders do not share state, any application that is replicated across multiple nodes must enable IP stickiness on the load balancer.