Security Findings Endpoints
This endpoint gives access to the list of security findings found when scanning the mobile apps.
See the Introduction for an overview of the API and information relevant to all API operations.
Security Findings Overview
There are two types of security findings in the Data Theorem portal:
- App Issues - these are findings that represent security issues that were found while scanning the mobile apps.
- App Protection Issues - these are findings that represent possible proactive security measures that were found while scanning the mobile apps.
The findings can be found in the following sections in the portal:
App Issues findings are shown as a single card when looking at an app’s issues:
App Protection findings are similarly shown as a single card when looking at an app’s protection tasks:
Findings have importance tags that are used internally by our service to characterize security findings. We expose these importance tags through the Mobile Security Results API because they can provide valuable insights to end-users. For example:
- Platform-specific store blockers can be identified with the
GOOGLE_P1andAPPLE_P1tags. - The presence of both the
DEFENSE_IN_DEPTHandSERVER_SIDEtags can be used to identify server-side App Protection issues.
Note: new kinds of importance tags may be added at any time. Integrations that use the Results API should be able to handle newly released tags.
We also return CVSS 3.1 scores and vectors as part of the response in the cvss3_score and cvss3_vector fields.
Values of Security Finding fields
Certain security finding fields take on predefined values:
status_group
CLOSEDOPEN
aggregated_status
OPEN- Found in the most recent scan as well as in the previous one
NEW- Found in the most recent scan
CLOSED_FIXED- A previously NEW or OPEN issue is now fixed (we detected a mechanism that mitigates the issue)
CLOSED_PARTIALLY_FIXED- A previously NEW or OPEN issue is now fixed (Deprecated)
CLOSED_WONT_FIX- A MANAGER or SECURITY role user (usually on our Portal) marked the issue as Won’t Fix
CLOSED_BY_POLICY- A MANAGER or SECURITY role user (usually on our Portal) marked the issue as Closed by Policy
CLOSED_RISK_ACCEPTED- A MANAGER or SECURITY role user (usually on our Portal) marked the issue as Risk Accepted
CLOSED_COMPENSATING_CONTROL- A MANAGER or SECURITY role user (usually on our Portal) marked the issue as Compensating Control
CLOSED_ITEM_NOT_FOUND- A previously NEW or OPEN issue is now not present (we did not detect the source of the issue)
OPEN_READY_TO_RESCAN- An issue is ready for rescan (Deprecated)
priority
P0P1P2P3P4
severity
HIGHMEDIUMLOW
category
DATA_AT_REST_EXPOSUREDATA_IN_TRANSIT_EXPOSUREDATA_LOSS_TO_HACKERSDATA_EXPOSURE_TO_THIRD_PARTY_APPSUNAUTHORIZED_DATA_COLLECTION
exploitability
DIFFICULTMODERATEEASY
compliance_policy
GDPRPCIHIPAAFTCOWASPCALOPPACOPPAVPPACCPA
Non-exhaustive list of compliance_criterion values, subject to revision:
OWASP_A1_2019OWASP_A2_2019OWASP_A3_2019OWASP_A4_2019OWASP_A5_2019OWASP_A6_2019OWASP_A7_2019OWASP_A8_2019OWASP_A9_2019OWASP_A10_2019OWASP_A1_2023OWASP_A2_2023OWASP_A3_2023OWASP_A4_2023OWASP_A5_2023OWASP_A6_2023OWASP_A7_2023OWASP_A8_2023OWASP_A9_2023OWASP_A10_2023OWASP_W1_2021OWASP_W2_2021OWASP_W3_2021OWASP_W4_2021OWASP_W5_2021OWASP_W6_2021OWASP_W7_2021OWASP_W8_2021OWASP_W9_2021OWASP_W10_2021OWASP_R1_2011OWASP_R2_2011OWASP_R3_2011OWASP_R4_2011OWASP_R5_2011OWASP_R6_2011OWASP_R7_2011OWASP_R8_2011OWASP_R9_2011OWASP_R10_2011OWASP_M1_2014OWASP_M2_2014OWASP_M3_2014OWASP_M4_2014OWASP_M5_2014OWASP_M6_2014OWASP_M7_2014OWASP_M8_2014OWASP_M9_2014OWASP_M10_2014OWASP_M1_2016OWASP_M2_2016OWASP_M3_2016OWASP_M4_2016OWASP_M5_2016OWASP_M6_2016OWASP_M7_2016OWASP_M8_2016OWASP_M9_2016OWASP_M10_2016OWASP_M1_2024OWASP_M2_2024OWASP_M3_2024OWASP_M4_2024OWASP_M5_2024OWASP_M6_2024OWASP_M7_2024OWASP_M8_2024OWASP_M9_2024OWASP_M10_2024OWASP_MSTG_ARCH_1OWASP_MSTG_ARCH_2OWASP_MSTG_ARCH_3OWASP_MSTG_STORAGE_1OWASP_MSTG_STORAGE_2OWASP_MSTG_STORAGE_3OWASP_MSTG_STORAGE_4OWASP_MSTG_STORAGE_5OWASP_MSTG_STORAGE_6OWASP_MSTG_STORAGE_7OWASP_MSTG_STORAGE_8OWASP_MSTG_STORAGE_9OWASP_MSTG_STORAGE_10OWASP_MSTG_STORAGE_11OWASP_MSTG_STORAGE_12OWASP_MSTG_STORAGE_13OWASP_MSTG_CRYPTO_1OWASP_MSTG_CRYPTO_2OWASP_MSTG_CRYPTO_3OWASP_MSTG_CRYPTO_4OWASP_MSTG_CRYPTO_5OWASP_MSTG_CRYPTO_6OWASP_MSTG_AUTH_1OWASP_MSTG_AUTH_2OWASP_MSTG_AUTH_3OWASP_MSTG_AUTH_4OWASP_MSTG_AUTH_5OWASP_MSTG_AUTH_6OWASP_MSTG_AUTH_7OWASP_MSTG_NETWORK_1OWASP_MSTG_NETWORK_2OWASP_MSTG_NETWORK_3OWASP_MSTG_NETWORK_4OWASP_MSTG_NETWORK_5OWASP_MSTG_PLATFORM_1OWASP_MSTG_PLATFORM_2OWASP_MSTG_PLATFORM_3OWASP_MSTG_PLATFORM_4OWASP_MSTG_PLATFORM_5OWASP_MSTG_PLATFORM_6OWASP_MSTG_PLATFORM_7OWASP_MSTG_CODE_1OWASP_MSTG_CODE_2OWASP_MSTG_CODE_3OWASP_MSTG_CODE_4OWASP_MSTG_CODE_5OWASP_MSTG_CODE_6OWASP_MSTG_CODE_7OWASP_MSTG_CODE_8OWASP_MSTG_CODE_9OWASP_ASVS_V_1_2OWASP_ASVS_V_1_4OWASP_ASVS_V_1_5OWASP_ASVS_V_1_6OWASP_ASVS_V_1_7OWASP_ASVS_V_1_9OWASP_ASVS_V_1_12OWASP_ASVS_V_1_14OWASP_ASVS_V_2_1OWASP_ASVS_V_2_2OWASP_ASVS_V_2_3OWASP_ASVS_V_2_5OWASP_ASVS_V_2_6OWASP_ASVS_V_2_7OWASP_ASVS_V_2_8OWASP_ASVS_V_2_10OWASP_ASVS_V_3_1OWASP_ASVS_V_3_2OWASP_ASVS_V_3_3OWASP_ASVS_V_3_4OWASP_ASVS_V_3_5OWASP_ASVS_V_3_7OWASP_ASVS_V_4_1OWASP_ASVS_V_4_2OWASP_ASVS_V_4_3OWASP_ASVS_V_5_1OWASP_ASVS_V_5_2OWASP_ASVS_V_5_3OWASP_ASVS_V_5_4OWASP_ASVS_V_5_5OWASP_ASVS_V_6_4OWASP_ASVS_V_7_4OWASP_ASVS_V_8_1OWASP_ASVS_V_8_2OWASP_ASVS_V_8_3OWASP_ASVS_V_9_1OWASP_ASVS_V_9_2OWASP_ASVS_V_10_2OWASP_ASVS_V_10_3OWASP_ASVS_V_11_1OWASP_ASVS_V_12_1OWASP_ASVS_V_12_3OWASP_ASVS_V_12_5OWASP_ASVS_V_12_6OWASP_ASVS_V_13_1OWASP_ASVS_V_13_2OWASP_ASVS_V_13_3OWASP_ASVS_V_13_4OWASP_ASVS_V_14_1OWASP_ASVS_V_14_2OWASP_ASVS_V_14_3OWASP_ASVS_V_14_4OWASP_ASVS_V_14_5OWASP_MASVS_PRIVACY_1OWASP_MASVS_PRIVACY_2OWASP_MASVS_PRIVACY_3OWASP_MASVS_PRIVACY_4PCI_DSS_v3_2_1_a1_2_1PCI_DSS_v3_2_1_a1_3PCI_DSS_v3_2_1_aA_2_1PCI_DSS_v3_2_1_a2_2_3PCI_DSS_v3_2_1_a2_3PCI_DSS_v3_2_1_a4_1PCI_DSS_v3_2_1_a6_1PCI_DSS_v3_2_1_a6_5_10PCI_DSS_v3_2_1_a6_6PCI_DSS_v3_2_1_a3_4PCI_DSS_v3_2_1_a10_1PCI_DSS_v3_2_1_a8_7NIST_800_53_AC_1NIST_800_53_AC_4NIST_800_53_AU_11NIST_800_53_SA_2NIST_800_53_SA_4NIST_800_53_SC_1NIST_800_53_SC_7NIST_800_53_SC_12NIST_800_53_SC_16NIST_800_53_SI_1NIST_800_53_SI_2NIST_800_53_CM_2NIST_800_53_CM_4FFIEC_VC2_REQUIREMENT_1FFIEC_VC2_REQUIREMENT_2FFIEC_VC2_REQUIREMENT_3FFIEC_VC2_REQUIREMENT_4FFIEC_VC2_REQUIREMENT_5FFIEC_VC2_REQUIREMENT_6FFIEC_VC2_REQUIREMENT_7FFIEC_VC2_REQUIREMENT_8FFIEC_VC2_REQUIREMENT_9CIS_BENCHMARK_GOOGLE_CLOUD_PLATFORM_1CIS_BENCHMARK_GOOGLE_CLOUD_PLATFORM_3CIS_BENCHMARK_GOOGLE_CLOUD_PLATFORM_4CIS_BENCHMARK_GOOGLE_CLOUD_PLATFORM_5CIS_BENCHMARK_GOOGLE_CLOUD_PLATFORM_6CIS_BENCHMARK_KUBERNETES_1CIS_BENCHMARK_KUBERNETES_3CIS_BENCHMARK_KUBERNETES_5CIS_BENCHMARK_AWS_1CIS_BENCHMARK_AWS_2CIS_BENCHMARK_AWS_3CIS_BENCHMARK_AZURE_3CIS_BENCHMARK_AZURE_4CIS_BENCHMARK_AZURE_6CIS_BENCHMARK_AZURE_7CIS_BENCHMARK_AZURE_8CIS_BENCHMARK_AZURE_9FEDRAMP_V5_API_SECURITY_SASTFEDRAMP_V5_API_SECURITY_DASTCALOPPA_22575CCPA_0COPPA_0FTC_2014_3FTC_2016_3FTC_2016_6FTC_2016_8FTC_2017_2FTC_2017_8FTC_2018_1FTC_2023_2FTC_2017_1FTC_1523054GDPR_0GDPR_1GDPR_2HIPAA_0MITRE_CWE_926MITRE_T1412MITRE_T1417MITRE_T1436MITRE_T1439MITRE_T1463MITRE_T1635_1MITRE_T1429MITRE_T1430MITRE_T1404MITRE_T1413MITRE_T1417_2MITRE_T1414MITRE_T1474MITRE_T1409MITRE_T1415MITRE_T1476MITRE_T1466MITRE_T1470MITRE_T1468MITRE_T1469MITRE_T1408PCI_SSC_TLS_REQUIREMENT_0PCI_DSS_v3_2_1_s8_2VPPA_0
Non-exhaustive list of importance_tags values, subject to revision:
APP_STORE_PRIVACY: Issues relevant to the App Store Answers toolkitAPPLE_P1: Apple App Store blockersCOFFEE_SHOP_COMPROMISE: Issues relevant to the Coffee Shop Compromise toolkitCUSTOMER_POLICY: Configurable issues. Eg, Presence of SDKs that are on an SDK deny-list.DATA_LEAKS: Issues that represent “data leaks” in the appDEFENSE_IN_DEPTH: App Protection issues. Represents an available defense-in-depth protection or mitigation that has not been implementedGOOGLE_P1: Google Play Store blockersKEYS_TO_THE_KINGOM: Issues relevant to the Keys to the Kingdom toolkitPRIVACY: Issues related to user privacySECURITY: Security issuesSECURITY_P1: Automatically categorized by Data Theorem as a Security P1 (user can override by changing the issue’s priority)SERVER_SIDE: Issues about services used by the app
List Security Findings
This endpoint provides a JSON object with a security_findings and a pagination_information keys. The
security_findings key contains a summary of all issues within a Data Theorem’s customer’s apps while the
pagination_information key provides cursor based pagination details for the JSON object response.
In addition to the issues data, the JSON object contains links to other API resources related to the current resource and a link to the issue on the customer facing portal.
The JSON object response can be filtered based on the following query parameters:
| field | type | description |
|---|---|---|
| cursor | string | pagination cursor as provided by the previous page |
| mobile_app_id | integer | select issues with for the given mobile app ID |
| results_since | string | select issues with changes no less recent than the provided date, expects ISO 8601 date format |
| status_group | string | select issues with the given status group, accepts values listed above |
| issue_type_id | UUID | select issues with the given issue type ID |
These fields may be included in the JSON response depending on the security finding:
| field | type | description |
|---|---|---|
| associated_cve_ids | list of strings | A list of CVEs which are related to the security finding |
| associated_cwe_ids | list of strings | A list of CWEs which are related to the security finding |
Sample Request
1 | GET https://api.securetheorem.com/apis/mobile_security/results/v2/security_findings |
Sample Response
1 | { |
Get Security Finding
This endpoint provides a JSON object which contains a summary of a specific issue within a DataTheorem’s customer’s
app specified by a security_finding_id.
Preconditions:
- The API key must have access to the security finding
Sample Request
1 | GET https://api.securetheorem.com/apis/mobile_security/results/v2/security_findings/:security_finding_id |
Sample Response
1 | { |
Patch Security Finding
This endpoint updates a security finding and provides a JSON object which contains a summary of the updated issue
within the DataTheorem’s customer’s app specified by security_finding_id.
Preconditions:
- The API key must have the permission to set issues priority when it modifies priority.
The request may update the following fields:
priority: The issue priority.
Sample Request
1 | PATCH https://api.securetheorem.com/apis/mobile_security/results/v2/security_findings/:security_finding_id |
Sample Response
1 | { |
Close Security Finding
This endpoint provides a means of closing a security finding specified by security_finding_id.
The given text description of the reason will be posted in a closing comment.
When a security finding is closed using this API operation, all open targets in that finding will be closed and the finding’s aggregated_status field will be updated with the most appropriate CLOSED_* status value.
To prevent any future scans from opening new targets, you can “permanently close” the finding by specifying "is_permanently_closed": true in the request body.
Otherwise, if the issue occurs somewhere else in a new build/release of the app, a new target may be opened.
Returns a 200 status code upon success with the updated security finding in the request body.
Preconditions:
- The API key must have access to the security finding
- The API key must have the
results_api.can_close_issuespermission - The security finding must be open
Expected request body format
The endpoint expects a JSON object to be passed in the request body.
| Field | Required | Type | Description |
|---|---|---|---|
aggregated_status |
✔️ | string | Status to set on the security finding, one of "CLOSED_WONT_FIX", "CLOSED_RISK_ACCEPTED", "CLOSED_COMPENSATING_CONTROL" |
is_permanently_closed |
boolean | Whether the security should be closed permanently, defaults to false |
|
reason |
✔️ | string | Arbitrary text, will appear in the closing comment |
Sample Request
1 | POST https://api.securetheorem.com/apis/mobile_security/results/v2/security_findings/:security_finding_id/close |
Sample Response
1 | { |
Post Comment on Security Finding
This API operation can create a new comment on an existing security finding. The new comment will be from the API Key
itself (the author_email field is set to the API Key’s “name” rather than to an email address), and by default the
comment is considered to be an “internal comment” or internal note. If a comment is intended as a question for Data
Theorem support, set is_question_for_datatheorem to true in the request body.
Upon success a 204 status code is returned with an empty response body.
Preconditions:
- The API key must have access to the security finding
- The API key must have the
results_api.can_comment_on_issuespermission
Expected request body format
The endpoint expects a JSON object to be passed in the request body.
| Field | Required | Type | Description |
|---|---|---|---|
text |
✔️ | string | Arbitrary text, the contents of the comment |
is_question_for_datatheorem |
bool | Set this to true if the comment is a question directed at Data Theorem support. If omitted, defaults to false, meaning that the comment is an internal comment. |
Sample Request
1 | POST https://api.securetheorem.com/apis/mobile_security/results/v2/security_findings/:security_finding_id/notes |
JSON body:
1 | { |
Sample Response
{
"author_email": "some@example.com",
"date_created": "2016-11-02T19:25:16.664990-00:00",
"id": "1234",
"is_internal_comment": "true",
"is_question_for_datatheorem": "false",
"is_reply_from_datatheorem": "false",
"text": "Lorem ipsum dolor sit amet."
}