Reading the API Security screens¶
API Security mirrors Application Security closely — same two-status model, same audit structure — with a handful of differences that matter when tracing a finding.
What is different from AppSec¶
| Application Security | API Security | |
|---|---|---|
| Asset | An application | An API asset — a collection of endpoints |
| Identified by | URL or package | Base URL, usually versioned |
| Finding attached to | The application | The API asset, and often a specific endpoint |
| Status column heading | Current Status | Current Status, under a different underlying name |
The last row is the practical one. The two modules hold the same concept under different names beneath the surface, so a report or export template built for one does not carry the other's status column — which is the usual reason an API export appears to be missing its status. Build the template against the module you intend to export.
The columns¶
| Column | Notes |
|---|---|
| Track ID | Quote in tickets; survives re-testing |
| Issue title | The finding, with its category |
| Risk | Severity, derived from the score |
| CVSS score | The raw score before context |
| Affected URL | The endpoint, not just the asset — the most useful column here |
| Validation status | Whether the finding is agreed |
| Client vuln status | What is being done about it |
| Discovered on | Last seen, not first |
| SLA duration / expiry | The window and the deadline |
| Creator | Who raised it — often a tester rather than a tool |
| Risk acceptance comment / date | Present inline where the finding was accepted |
Affected URL is where API findings differ in practice¶
An application finding says "this app has XSS". An API finding says "this endpoint accepts an unauthorised object reference" — and the endpoint is the actionable part.
Two consequences:
- The same weakness on two endpoints is two findings, correctly. Fixing one does not close the other, and a shared fix in middleware closes both only when the next assessment confirms it.
- Grouping by affected URL is usually more useful than grouping by severity, because it maps to the code that has to change.
Why API findings are often manual¶
Automated scanners struggle with APIs: they need a specification, valid authentication and realistic payloads to reach anything interesting. Much of what matters — broken object level authorisation, excessive data exposure, mass assignment — requires understanding what the endpoint is for.
So a higher proportion of API findings are raised by a tester than by a tool, which is why the Creator column is worth reading and why evidence attached to the finding carries more weight here than in a scanner-driven module.
Audits scope the list¶
Like AppSec, this screen always shows findings within an audit. A finding you expect and cannot see is usually in a different audit rather than missing — check the audit selector before treating it as absent.