> ## Documentation Index
> Fetch the complete documentation index at: https://docs.base44.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security findings

> Security scanner findings endpoint in the Compliance API

`GET /{workspace_id}/security-findings`

Returns findings from Base44's built-in security scanner and from other scanners the customer has connected, such as Wiz, unified in one shape. Requires `compliance:findings:read`.

| Field | Type | Notes |
| - | - | - |
| `id` | string | Stable finding ID. Deduplicate on this. |
| `app_id` | string | |
| `category` | string | One of `rls`, `secrets`, `backend_functions`, `dependencies`, `code`, `security_headers`, or `third_party`. |
| `severity` | string | One of `critical`, `high`, `medium`, or `low`. This is the finding's own rating where the scanner records one. Otherwise it's the category's fixed rating: `rls` and `secrets` are critical, `backend_functions` is high, and the rest are medium. |
| `title`, `description` | string | Sanitized, with no secret values and no internal URLs. |
| `location` | object | One shape with irrelevant fields null: `{ entity_name }`, `{ file_path, line }`, or `{ package_name, version }`. |
| `status` | string | `open`, `resolved`, or `dismissed`. Treat `open` as "not known to be resolved". |
| `scanned_at` | timestamp or null | When the reporting scan ran. |
| `source` | string | `base44_scanner` or `wiz`. Extensible. |

## Behavior to build around

* **Third-party scanners:** A finding from a scanner that isn't Base44's carries the category `third_party`, with `source` naming which one. A dependency vulnerability found by Wiz is therefore `third_party` rather than `dependencies`, because category reflects the scanner family. One package upgrade can resolve a row of each together.
* **Snapshots:** Findings are a latest-scan snapshot. There's no per-finding first-seen time, and `scanned_at` is when the reporting scan ran. A scan section that failed or didn't run contributes no rows, rather than an empty list that would read as clean.
* **Stable IDs:** An `id` is stable for as long as the finding's location is. For `secrets`, `backend_functions`, and `code` it also covers the file's contents, so editing an unrelated line of the same file re-keys a finding that hasn't otherwise changed. A diff on `id` reads that as one finding closing and another opening. The `rls` and `dependencies` categories use natural keys and don't move.
* **Security headers:** The `security_headers` category is sparse rather than absent. These are recommendations derived from an app's own configuration at scan time rather than a scan section, so they carry no location and appear only for apps scanned since the platform began recording them. Don't read absence as a clean result.
* **Apps without login:** On an app that doesn't require login, every backend function is callable by anyone by design, so `backend_functions` lists each function once. One the scanner flags as abusable keeps high severity and the scanner's description, as does flagged code that isn't a function, such as a server route. The rest are low. Switching an app in or out of that mode replaces one set of rows with the other on the next scan, under new `id` values.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.