Getting Started
Zscaler provides secured access to cloud service API, Sandbox Submission API, and 3rd-Party App Governance API using different authentication schemes:
If you need to obtain API keys, authenticate into, and make calls using Zscaler OneAPI endpoints, see API Client Authentication in ZIdentity and Getting Started with OneAPI.
| API | Supported Authentication Methods |
|---|---|
| Cloud Service API |
|
| Sandbox Submission API | Combination of Basic Authentication and API Token |
| 3rd-Party App Governance API | API Key. Contact Zscaler Support if you do not have a valid API key. |
OAuth 2.0 Authentication
OAuth 2.0 allows third-party applications to obtain controlled access to protected resources using access tokens. Zscaler uses the Client Credentials grant type, in which the clients exchange their credentials for an access token. For more information, see Securing ZIA APIs with OAuth 2.0.
Zscaler recommends the OAuth 2.0 authentication method for accessing the cloud service API.
Your organization must meet the following prerequisites before you can access the API:
- Prerequisites for OAuth 2.0 Authentication
Your organization must meet the following requirements to be able to use OAuth 2.0 authentication.
- You must have an API subscription. If you do not have a subscription, submit a Zscaler Support ticket.
- You must have the API Roles configured in the ZIA Admin Portal.
- You must have your client applications registered on your authorization server (i.e., PingFederate, Okta, or Azure AD) with the required scope and configured appropriately. To learn how to set up client applications on your OAuth 2.0 service provider, refer to the respective help documentation.
- You must have your OAuth 2.0 authorization server added to the ZIA Admin Portal.
When the prerequisites are met, you can securely access the API in the following way:
- 1. Retrieve your base URL.
The host and basePath for the cloud service API is
$zsapi.<Zscaler Cloud Name>/api/v1. Check which Zscaler cloud name was provisioned for your organization and use it to replace<Zscaler Cloud Name>. For example:zsapi.zscalerbeta.netzsapi.zscalerone.netzsapi.zscalertwo.netzsapi.zscalerthree.netzsapi.zscaler.netzsapi.zscloud.net
To locate your base URL:
- Log in to the ZIA Admin Portal using your admin credentials. You must be assigned an admin role that includes the Authentication Configuration functional scope.
- Go to Administration > Cloud Service API Security.
- On the OAuth 2.0 Authorization Servers tab, the base URL is displayed within the table.
- 2. Authenticate the client and retrieve an access token.
You need to configure the client application registered with the authorization server to send a POST request to the token endpoint with the following parameters and retrieve an access token:
- client_id: A unique, public identifier issued to the client application during registration with the authorization server. This identifier is used with
client_secretfor authentication. This information is obtained from the OAuth 2.0 service console. - client_secret: A secret string used by the client application for authenticating with the authorization server. This information is obtained from the OAuth 2.0 service console.
- grant_type: The OAuth flow that defines the various methods in which a client application can obtain an authorization grant from the authorization server and the sequence in which the OAuth 2.0 authorization process takes place. The Zscaler service uses the
client_credentialsgrant type, which allows clients to access protected resources outside of the context of users. - scope: Scope defines the permissions required by the client application to access the API. You must configure the scope value in the
<Zscaler Cloud Name>::<Org ID>::<API Role>format, where:<Zscaler Cloud Name>represents the cloud on which your organization is provisioned.<Org ID>represents your organization ID obtained from the ZIA Admin Portal (under Administration > Settings > Company Profile).<API Role>represents an API role configured in the ZIA Admin Portal (under Administration > Authentication > Role Management).
For example,
zscalerbeta.net::8956412::sampleRoleThe client makes a POST request to the token endpoint with the client credentials (client ID and client secret) presented using HTTP Basic authentication. Alternatively, the client credentials can also be provided using the
client_idandclient_secretparameters in the body of the POST request. For more information, refer to OAuth 2.0 RFC 6749, section 2.3.Example POST request to the token endpoint:
POST /as/token.oauth2 HTTP/1.1 Host: localhost:9031 Authorization: Basic xxxxxxx Content-Type: application/x-www-form-urlencoded { "grant_type": "client_credentials", "scope": "zscalerbeta.net::8956412::sampleRole" }If the request is successful, a 200 OK response is returned to the client with the access token and other information in a JSON structure, as follows:
HTTP/1.1 200 OK Date: Thu, 25 Aug 2022 11:35:21 GMT X-FRAME-OPTIONS: SAMEORIGIN Referrer-Policy: origin Cache-Control: no-cache, no-store Pragma: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Type: application/json;charset=utf-8 Set-Cookie: PF=QL6IbHFouxkNFPXZ6uQT06;Path=/;Secure;HttpOnly;SameSite=None Transfer-Encoding: chunked { "access_token": "xxxxxxx", "token_type": "Bearer", "expires_in": 7199 } PF QL6IbHFouxkNFPXZ6uQT06If an unsuccessful POST request is made to the token endpoint, the response code returns a 400 error.
Close - client_id: A unique, public identifier issued to the client application during registration with the authorization server. This identifier is used with
- 3. Make an API call.
When making API calls, the client must pass the access token in each API request for authentication. The client can present the access token in the request Authorization header using the bearer authentication scheme.
You can write an automation script to enable the client to dynamically retrieve the access token before passing the token in an API request.
In the following example, we look up categories for a specified list of URLs using
/urlLookup.Send a POST request to
/urlLookup:POST /api/v1/urlLookup HTTP/1.1 Host: zsapi.zscalerbeta.net Content-Type: application/json Authorization: Bearer xxxxxxx Cache-Control: no-cache [ "viruses.org", "facebook.com", "bbc.com" ]A successful response to this POST request returns the list of URLs with their category information:
HTTP/1.1 200 OK Strict-Transport-Security: max-age=31622400; includeSubDomains; preload X-FRAME-OPTIONS: SAMEORIGIN Transfer-Encoding: chunked Content-Type: application/json Date: Tue, 26 Sep 2017 23:28:21 GMT Server: Zscaler [ { "url": "viruses.org", "urlClassifications": [ "MISCELLANEOUS_OR_UNKNOWN" ], "urlClassificationsWithSecurityAlert": [] }, { "url": "facebook.com", "urlClassifications": [ "SOCIAL_NETWORKING" ], "urlClassificationsWithSecurityAlert": [] }, { "url": "bbc.com", "urlClassifications": [ "NEWS_AND_MEDIA" ], "urlClassificationsWithSecurityAlert": [] } ]Zscaler recommends sending URLs for lookup in batches. Each request can have up to 100 URLs maximum, and each URL cannot exceed 1,024 characters. To learn more, see URL Categories in the API Reference and Configuring URL Categories Using API.
When the Zscaler service receives an API request, it validates the access token and accepts the request if authorization is successful. The Zscaler service then extracts the JWT from the request's authorization header and validates the JWT signature using the authorization server's public key fetched from the JWKS endpoint. After successful validation, the client is allowed to access the requested API resources.
The Zscaler service caches the public key set for a brief period of time. If the caching period expires or if the public keys are rotated by the authorization server, then the validation may fail. In such cases, the Zscaler service queries the JWKS endpoint to fetch the public key set. So, you need to program your client application to resend an API request after a minute if the authorization fails for the first time.
If the API call fails due to an upgrade or scheduled maintenance of the API service, a 403 error code is returned, as shown in the following sample response. The API service supports only read operations via GET requests during this period.
HTTP/1.1 403 x-zscaler-mode: read-only { "code": "STATE_READONLY", "message": "The API service is undergoing a scheduled upgrade and is in read-only mode." }When making API calls, consider the following best practices:
- Ensure that the lifetime of the access token is set to a desirable value in the OAuth 2.0 service console.
- When updating a resource, always send a GET request before the PUT request. This retrieves the current values for the resource before you update the entire resource with new values.
To send ad hoc requests to the API, Zscaler recommends using the Postman REST API client.
Close - 4. Activate configuration changes.
After modifying any configurations, you must activate the changes by sending a POST request to
/status/activate. As a best practice, if you are making multiple configuration changes, Zscaler recommends grouping the changes and activating once.To avoid race conditions, do not manually change configuration settings via the ZIA Admin Portal while your scripts are running. The Zscaler service might lock a configuration while a user is editing. When multiple users are editing concurrently, only one user's change succeeds while the remaining users might receive a 409 error (EDIT_LOCK_NOT_AVAILABLE).
If you encounter a race condition and a 409 error code is returned, Zscaler recommends adding a wait cycle of a few seconds and retrying to recover.
You can retrieve the activation status by sending a GET request to
Close/status. However, you cannot revert a change and any queued activations cannot be canceled. To learn more, see Activation in the API Reference and Saving and Activating Changes in the ZIA Admin Portal.
To learn more about rate limiting and HTTP status codes, see Understanding Rate Limiting and API Response Codes and Error Messages. If you encounter any issues with the API, contact Zscaler Support.
Using ZIA Admin Credentials and API Key/Token
In this method, API authentication is based on a combination of the API key and ZIA admin credentials (i.e., username and password).
Before getting started, make sure that your organization has an API subscription and an API key/token enabled. If you do not have a valid subscription, submit a Zscaler Support ticket. To learn more, see Managing Cloud Service API Key and Managing Sandbox API Token.
In ZIdentity-enabled tenants, administrators accessing the ZIA APIs must be hosted on ZIdentity with appropriate roles assigned from ZIA. Users provisioned via third-party identity providers (IdPs) cannot authenticate to the APIs.
As a security best practice, it is highly recommended that you create a dedicated admin role and user with restricted functional scope access within the ZIA Admin Portal. This helps ensure correct usage, avoids potential conflicts between API and ZIA Admin Portal logins, and prevents misuse.
When these prerequisites are met, you can securely access the API in the following way:
- 1. Retrieve your base URL and API key/token.
The host and basePath for the cloud service API is
$zsapi.<Zscaler Cloud Name>/api/v1. Check which Zscaler cloud name was provisioned for your organization and use it to replace<Zscaler Cloud Name>. For example:zsapi.zscalerbeta.netzsapi.zscalerone.netzsapi.zscalertwo.netzsapi.zscalerthree.netzsapi.zscaler.netzsapi.zscloud.net
If you are accessing the Sandbox Submission API, your host and basePath is
$csbapi.<Zscaler Cloud Name>/zscsb. (e.g.,$csbapi.zscalerbeta.net/zscsb).To locate your base URL and key/token:
- Log in to the ZIA Admin Portal using your admin credentials.
- Go to Administration > Cloud Service API Key Security.
To view the Cloud Service API Key Management page, the admin must be assigned an admin role that includes the Authentication Configuration functional scope.
- For the cloud service API, on the Cloud Service API Key tab, the base URL and key details are displayed within the table. For the Sandbox Submission API, the base URL and token are displayed on the Sandbox Submission API Token tab.
An organization can only have one API key or token (i.e., one key for the cloud service API and one token for the Sandbox Submission API). To learn more, see About Cloud Service API Key Management.
Close - 2. Authenticate and create an API session.
- Obfuscate the API key using one of the following
obfuscateApiKey()implementation methods:- PHP
/** * @param int $obfuscateTimestamp in MICROseconds * @param string $apiKey * @return string */ private static function obfuscateApiKey($obfuscateTimestamp, $apiKey) { $n = substr($obfuscateTimestamp, -6); $r = $n >> 1; $r = str_pad($r, 6, '0', STR_PAD_LEFT); $obfuscatedApiKey = ''; for ($i = 0; $i < strlen($n); $i++) { $pos = substr($n, $i, 1); $obfuscatedApiKey .= substr($apiKey, $pos, 1); } for ($j = 0; $j < strlen($r); $j++) { $pos = substr($r, $j, 1) + 2; $obfuscatedApiKey .= substr($apiKey, $pos, 1); } return $obfuscatedApiKey; }The following code is then used to fetch the session cookie (
JSESSIONID). To learn more aboutJSESSIONID, see step 2):$obfuscateTimestamp = (int)(microtime(true) * 1000); $obfuscatedApiKey = self::obfuscateApiKey($obfuscateTimestamp, 'your_api_key');By default, the
Closemicrotime(true)function would return a float representing the current time in seconds. So, in the code example,microtime(true)is multiplied by 1000 to ensure that the function returns the timestamp in microseconds. - PowerShell
function obfuscateApiKey { param ( [string] #Your API key $apiKey, [string] #Timestamp $timestamp ) $high = $timestamp.substring($timestamp.length - 6) $low = ([int]$high -shr 1).toString() $obfuscatedApiKey = '' while ($low.length -lt 6) { $low = '0' + $low } for ($i = 0; $i -lt $high.length; $i++) { $obfuscatedApiKey += $apiKey[[int64]($high[$i].toString())] } for ($j = 0; $j -lt $low.length; $j++) { $obfuscatedApiKey += $apiKey[[int64]$low[$j].ToString() + 2] } return $obfuscatedApiKey }Close - Python
import time def obfuscateApiKey (): seed = 'YOUR_API_KEY' now = int(time.time() * 1000) n = str(now)[-6:] r = str(int(n) >> 1).zfill(6) key = "" for i in range(0, len(str(n)), 1): key += seed[int(str(n)[i])] for j in range(0, len(str(r)), 1): key += seed[int(str(r)[j])+2] print("Timestamp:", now, "\tKey", key) obfuscateApiKey()Python 2.x Implementation:
import time def obfuscateApiKey (): seed = 'YOUR_API_KEY' now = str(long(time.time() * 1000)) n = now[-6:] r = str(int(n) >> 1).zfill(6) key = "" for i in range(0, len(n), 1): key += seed[int(n[i])] for j in range(0, len(r), 1): key += seed[int(r[j])+2] print "Timestamp:%s Key:%s" % (now, key) obfuscateApiKey()Close - Java
/** * obfuscateApiKey java method to obfuscate an API key based on current time * stamp * * @param key * @param timestamp * @return the obfuscated API key to use in POST /authenticatedSession */ private static String obfuscateApiKey(String key, String timestamp) { int apiKeySize = 12; String retVal = ""; char[] key1Arr = key.substring(0, apiKeySize - 2).toCharArray(); char[] key2Arr = key.substring(2).toCharArray(); String hiIndices = timestamp.substring(timestamp.length() - 6); int hitime = Integer.valueOf(hiIndices); int lotime = hitime >> 1; String loIndices = String.format("%06d", lotime); for (char index : hiIndices.toCharArray()) { retVal += key1Arr[index - '0']; } for (char index : loIndices.toCharArray()) { retVal += key2Arr[index - '0']; } return retVal; }Close - JavaScript
obfuscateApiKey: function(timestamp, key) { var high = timestamp.substring(timestamp.length - 6); var low = (parseInt(high) >> 1).toString(); var apiKey = ""; while (low.length < 6) { low = "0" + low; } for (var i = 0; i < high.length; i++) { apiKey += key.charAt(parseInt(high.charAt(i))); } for (var j = 0; j < low.length; j++) { apiKey += key.charAt(parseInt(low.charAt(j)) + 2); } return apiKey; }Close - Shell Script
epoch=$(date +%s000) mykey={your API key} key="" n=${epoch:(-6)} o=`printf %06d $((10#$n >> 1))` for ((i=0; i<${#n}; i++)); do tmp=${n:$i:1} key+=${mykey:$tmp:1} done for ((j=0; j<${#o}; j++)); do tmp=${o:$j:1}+2 key+=${mykey:$tmp:1} doneClose
- PHP
- To authenticate via the API and create a new session, send a POST request to
/authenticatedSessionwith the following parameters:
username: A string that contains the email ID of the API admin.password: A string that contains the password for the API admin.apiKey: A string that contains the obfuscated API key (i.e., the return value of theobfuscateApiKey()method).timestamp: A string that contains a long value that represents the current time in milliseconds since midnight, January 1, 1970 UTC. This timestamp value is used to obfuscate the API key given by Zscaler.
Example POST request to
/authenticatedSession:POST /api/v1/authenticatedSession HTTP/1.1 Host: zsapi.zscalerbeta.net Content-Type: application/json Cache-Control: no-cache { "apiKey": "s0m3rAnd0mKey", "username": "adminXYZ@acme.com", "password": "s0m3pa55w0rd", "timestamp": "1389681124480" }A successful response to this POST request would be:
HTTP/1.1 200 OK Strict-Transport-Security: max-age=31622400; includeSubDomains; preload X-FRAME-OPTIONS: SAMEORIGIN Transfer-Encoding: chunked Content-Type: application/json Date: Tue, 26 Sep 2017 23:24:15 GMT Set-Cookie: JSESSIONID=B875640E5EB2DA2C20CF191AE21F91B1; Path=/; Secure; HttpOnly Server: Zscaler {"authType":"ADMIN_LOGIN","obfuscateApiKey":true} JSESSIONID = B875640E5EB2DA2C20CF191AE21F91B1The Zscaler service checks that the
timestamppassed by thePOST /authenticatedSessionrequest meets the following conditions:- It is the same
timestampused to obfuscate the API key using theobfuscateApiKey()method. - It is within a two-hour range of Zscaler's measured epoch time.
A successful response to
/authenticatedSessionreturns a cookie in theSet-Cookieheader, calledJSESSIONID, that must be used in subsequent requests. By default, theJSESSIONIDexpires within 30 minutes from the last activity or request on that session, or when you explicitly log out by sending a DELETE request to/authenticatedSession. However, the default session timeout interval can be changed, from 5 minutes to 600 minutes (10 hours), within the ZIA Admin Portal. If API calls are made after the expiry ofJSESSIONID, a 401 error is returned. To resume making API calls, reauthenticate the API by sending a POST request to/authenticatedSession.If an unsuccessful POST request is made to
/authenticatedSessionthe response code returns a 400 error, such as:{"code":"INVALID_USERNAME_OR_PASSWORD","message":"Invalid email or password"}To learn more, see API Response Codes and Error Messages.
Close - Obfuscate the API key using one of the following
- 3. Make an API call.
Try making an API call. In the following example, we look up categories for a specified list of URLs using
/urlLookup.Send a POST request to
/urlLookup:POST /api/v1/urlLookup HTTP/1.1 Host: zsapi.zscalerbeta.net Content-Type: application/json Cache-Control: no-cache [ "viruses.org", "facebook.com", "bbc.com" ]A successful response to this POST request returns the list of URLs with their category information:
HTTP/1.1 200 OK Strict-Transport-Security: max-age=31622400; includeSubDomains; preload X-FRAME-OPTIONS: SAMEORIGIN Transfer-Encoding: chunked Content-Type: application/json Date: Tue, 26 Sep 2017 23:28:21 GMT Server: Zscaler [ { "url": "viruses.org", "urlClassifications": [ "MISCELLANEOUS_OR_UNKNOWN" ], "urlClassificationsWithSecurityAlert": [] }, { "url": "facebook.com", "urlClassifications": [ "SOCIAL_NETWORKING" ], "urlClassificationsWithSecurityAlert": [] }, { "url": "bbc.com", "urlClassifications": [ "NEWS_AND_MEDIA" ], "urlClassificationsWithSecurityAlert": [] } ]Zscaler recommends sending URLs for lookup in batches. Each request can have up to 100 URLs, and a URL cannot exceed 1,024 characters. To learn more, see URL Categories in the API Reference and Configuring URL Categories Using API.
If the API call fails due to an upgrade or scheduled maintenance of the API service, a 403 error code is returned, as shown in the following sample response. The API service supports only read operations via GET requests during this period.
HTTP/1.1 403 x-zscaler-mode: read-only { "code": "STATE_READONLY", "message": "The API service is undergoing a scheduled upgrade and is in read-only mode." }When making API calls, consider the following best practices:
- Always pass the
JSESSIONIDcookie with the request. - Use UTF-8 encoding for all endpoints (e.g., use the
encodeUriComponent()function in JavaScript to encode to UTF-8). - When updating a resource, always send a GET request before the PUT request. This retrieves the current values for the resource before you update the entire resource with new values. After the update, the next GET request for that resource returns the new values.
By using this practice you can avoid potentially missing updates between GET and PUT calls.
- Prevent API call caching by adding a dummy argument with a randomly generated number to all URL request strings. For example:
GET /urlCategories?_=123456- Create a dedicated user for each script. Don't use the same user in multiple scripts that are running concurrently.
- Create an authenticated session only if an API call returns a 401 error (SESSION_NOT_VALID), which indicates that the authenticated session has expired or it does not exist. To learn how to create an authenticated session, see Authenticate and create an API session.
To send ad hoc requests to the API, Zscaler recommends using the Postman REST API client.
Close - Always pass the
- 4. Activate configuration changes.
After modifying any configurations, you must activate the changes by sending a POST request to
/status/activate. The API change activation request is queued and does not override any simultaneous changes by other admins. As a best practice, if you are making multiple configuration changes, Zscaler recommends grouping the changes and activating once.To avoid race conditions, do not manually change configuration settings via the ZIA Admin Portal while your scripts are running. The Zscaler service might lock a configuration while a user is editing. When multiple users are editing concurrently, only one user's change succeeds while the remaining users might receive a 409 error (EDIT_LOCK_NOT_AVAILABLE).
If you encounter a race condition and a 409 error code is returned, Zscaler recommends adding a wait cycle of a few seconds and retrying to recover.
The Zscaler service automatically activates the saved changes if the admin:
- is inactive for a specific duration as configured in the Advanced Settings
- logs out using DELETE
/authenticatedSession
You can retrieve the activation status by sending a GET request to
Close/status. However, you cannot revert a change and any queued activations cannot be canceled. To learn more, see Activation in the API Reference and Saving and Activating Changes in the ZIA Admin Portal. - 5. Log out of the API.
To log out of an authenticated API session, send a DELETE request to
Close/authenticatedSession.
To learn more about rate limiting and HTTP status codes, see Understanding Rate Limiting and API Response Codes and Error Messages. If you encounter any issues with the API, contact Zscaler Support.
Using 3rd-Party App Governance API Key
3rd-Party App Governance API authentication is based on your API key, which is provided to you if you have an 3rd-Party App Governance trial or license. If you do not have a valid API key, submit a Zscaler Support ticket.
When this prerequisite is met, you can securely access the API in the following way:
- 1. Use the base URL.
The base URL for the 3rd-Party App Governance API is
Closehttps://api.apptotal.zscaler.com/v1/. - 2. Make an API call.
When making an API call, consider the following best practices:
- For query parameters, ensure that the provided characters adhere to the specifications outlined in RFC 7230 and RFC 3986.
- Special characters and encoding must follow the standards defined in RFC 3986.
Try making an API call. In the following example, we search for a specified application using
/apps/app.Send a GET request to
https://api.apptotal.zscaler.com/v1/apps/app. In your request, enter the app ID of your desired application and your provided API key.The following GET request uses cURL. You can use other applicable methods.
curl --request GET 'https://api.apptotal.zscaler.com/v1/apps/app?app_id=22c49a0d-d21c-4792-aed1-8f163c982546' --header 'X-API-KEY: <Your Provided API Key>'
A successful response to this GET request returns the application with its information.
CloseHTTP/1.1 200 Access-Control-Allow-Origin: * Access-Control-Allow-Headers: Origin, Content-Type, Accept, Authorization, X-Token Content-Security-Policy: default-src 'self' X-Content-Type-Options: nosniff X-XSS-Protection: 1 Strict-Transport-Security: max-age=31536000; includeSubDomains Cache-Control: no-store X-Rate-Limit-Remaining: 985 vary: accept-encoding Content-Type: application/json;charset=UTF-8 Transfer-Encoding: chunked Date: Wed, 27 Mar 2024 09:50:04 GMT { "name":"OneDrive Free Client", "publisher":{ "name":"Skilion", "description":"A complete tool to interact with OneDrive on Linux.", "siteUrl":"https://skilion.github.io/onedrive/", "logoUrl":null }, "platform":"Azure AD", "description":"A complete tool to interact with OneDrive on Linux.", "redirectUrls":[ "urn:ietf:wg:oauth:2.0:oob", "https://login.microsoftonline.com/common/oauth2/nativeclient" ], "websiteUrls":[ ], "categories":[ "Productivity" ], "tags":[ "Application", "OAuth", "Enterprise App", "3rd Party" ], "permissionLevel":10.0, "riskScore":9.030265, "risk":"HIGH", "externalIds":[ { "id":"22c49a0d-d21c-4792-aed1-8f163c982546", "type":"appId" } ], "clientId":"22c49a0d-d21c-4792-aed1-8f163c982546", "permissions":[ { "scope":"Files.ReadWrite.All", "service":"OneDrive", "description":"Allows the app to read, create, update and delete all files that you can access.", "accessType":"Broad Data Access", "level":"HIGH" }, { "scope":"offline_access", "service":"Azure AD", "description":"Allows the app to see and update the data you gave it access to, even when you are not currently using the app. This does not give the app any additional permissions.", "accessType":"Account Access", "level":"MEDIUM" }, { "scope":"Files.ReadWrite", "service":"OneDrive", "description":"Allows the app to read, create, update, and delete your files.", "accessType":"Account Access", "level":"HIGH" }, { "scope":"Sites.ReadWrite.All", "service":"SharePoint", "description":"Allows the app to create, read, update, and delete documents and list items in all site collections without a signed in user.", "accessType":"Broad Data Access", "level":"HIGH" } ], "compliance":[ ], "dataRetention":null, "logoUrl":"https://secure.aadcdn.microsoftonline-p.com/dbd5a2dd-otrskziqqxxsssdghj7jjfrifoprytjmtmfdfhco0ss/appbranding/rtuwslp0buv8m-wvdsueqwxengpcnles4xgny6zu36w/1033/bannerlogo?ts\u003d636247467025774044", "privacyPolicyUrl":"https://drive.google.com/open?id\u003d1HpfY2gd6nSvtF1CKJXf7U7X86yGl8v_C", "termsOfServiceUrl":"https://drive.google.com/open?id\u003d10ybu7HmZBnGX-PkvrJTIquXjolmX3Xog", "marketplaceUrl":null, "marketplaceData":{ "stars":0.0, "downloads":0, "reviews":0 }, "platformVerified":false, "clientTypes":[ ], "developerEmail":null, "supportEmail":null, "consentScreenshot":null, "ipAddresses":[ ], "extractedUrls":null, "extractedApiCalls":null, "vulnerabilities":null, "apiActivities":null, "risks":[ { "name":"Unmanaged Data Storage", "description":"\n \n* Third-party file management apps and services often let end-users connect their devices to company managed SaaS storage providers (such as OneDrive, GDrive, Box, etc.). This often entails several risks that managed apps try to over come:\n \n* They may store files locally on end-users devices in an unsecured manner -- e.g. unencrypted\n \n* They cannot be remotely wiped on employee off-boarding or lost/stolen device\n \n* They often let end-users manage other SaaS storage integrations -- such as personal accounts on SaaS providers or even a different company drive altogether (e.g. contractor); End-user may often copy or transfer company data to such other services, intentionally or by mistake.\n \n* They may extract some or all of the SaaS storage data onto their own data-centers -- based on the individual app architecture. Whereas the managed service provider has often gone thru appropriate security diligence and the relevant protections have been enabled, the unmanaged storage provider data protections, retention and security are unverified.", "summary":null, "evidence":null, "category":"Overprivileged", "severity":"MEDIUM" }, { "name":"Platform Unverified App", "description":"\n \n* A verified app is a third-party app that's been reviewed by the platform to ensure compliance with security and privacy requirements. Third-party apps that haven't been verified by the platform might be subject to restrictions. Note that well-known apps might not be listed as verified.\n \n* The verification process for an app might not be completed for the following reasons: (1) The app developer isn\u0027t accessing sensitive data and isn\u0027t required to submit the app for verification yet (2) The app developer is accessing sensitive data but hasn\u0027t requested verification yet (3) The app developer is accessing sensitive data and has been rejected because they use an unsupported application type or don\u0027t meet the requirements.\n ", "summary":null, "evidence":null, "category":"Potentially Harmful", "severity":"LOW" }, { "name":"Unverified General Secrets Leak", "description":"\n \n* A secret is anything that controls access to a resource or service.\n A secret can be API keys, passwords, certificates, tokens, and more.\n \n* Apps, either commercial or open-source,\n frequently rely on third-party services and use different types of secrets to access them.\n \n* When a secret of any third-party service is visible in an open-source repository, even\n if not directly of the Oauth app, it might point to lack of credential hygiene policies\n on the developer side.\n \n* In some cases, the leak might allow malicious actor access to the developers infrastructure,\n and from there to their customer data.\n \n* Unverified status notes that the identified secrets could not be validated by Canonic\n ", "summary":null, "evidence":"- Publicly available secrets were found on OneDrive Free Client GitHub repository - https://github.com/skilion/onedrive\n- \u003chttps://github.com/skilion/onedrive/commit/0efc2fe3824a4b1d3e46f6bf8a864d28bd4efdfc\u003e\n- \u003chttps://github.com/skilion/onedrive/commit/b32fef74fdb56616b46f14756702750e5520213e\u003e\n- \u003chttps://github.com/skilion/onedrive/commit/00d53f648ec13f3738fb1fd7d597d07470fee578\u003e\n", "category":"Potentially Harmful", "severity":"MEDIUM" }, { "name":"App Vulnerable To Device Flow Phishing", "description":"\n \n* The OAuth device code flow allows users to sign in to input-constrained devices such as a smart TV, IoT device, or printer.\n \n* This flow, while useful, can be exploited by an attacker to phish user's access tokens.\n \n* If an attacker initiates the flow, unaware users can be easily tricked, since they seem to consent to the real app.\n \n* This technique has been gaining popularity among threat actors as seen in multiple recent breaches.\n ", "summary":null, "evidence":"\n* The app has been configured to support the device code flow without requiring the app client-secret verification", "category":"Potentially Harmful", "severity":"MEDIUM" }, { "name":"Open-Source App", "description":"\n \n* The application\u0027s source code is publicly available online.\n \n* Open Source projects are available in public repositories and might expose secrets or certificates.\n \n* Malicious actors can review the code for exploitable vulnerabilities.\n ", "summary":null, "evidence":"https://github.com/skilion/onedrive\n", "category":"Potentially Harmful", "severity":"LOW" } ], "insights":[ ], "instances":[ ], "canonicVerified":trueClose
Rate limits throttle the number of API calls you can make. The following rate limits apply to all 3rd-Party App Governance API endpoints:
- Trial: 25 per day
- License: 1,000 per day
To learn more about HTTP status codes, see the API Reference. If you encounter any issues with the API, contact Zscaler Support.