Skip to content

API Security

API Security tracks weaknesses in service endpoints — the interfaces your applications, partners and mobile apps call. APIs are assessed separately from the applications that use them, because they are separately exposed and separately exploitable.

Why APIs get their own module

An API is often reachable by more parties than the application in front of it, and it rarely has the protections a user interface does. The characteristic API weaknesses are also different in kind:

  • Authorisation flaws — a caller can request another customer's record simply by changing an identifier. The most common and most damaging API weakness.
  • Excessive data exposure — the response contains more than the caller needs, and the filtering happens in the client.
  • Missing rate limits — an endpoint that can be called without restriction.
  • Forgotten versions — an old API version left reachable after its replacement shipped.

None of these are visible from the user interface of the application using the API, which is why the API is assessed in its own right.

How the module is organised

API Security dashboard

The API Security dashboard.
Screen Shows
Dashboard API posture at a glance
Audits Assessments performed against your APIs
Vulnerabilities The findings from those assessments

The lifecycle is the same as everywhere else in NxSAM: findings are discovered, approved, given an SLA by severity, remediated, then validated to close.

Identifying the asset

API assets are identified by their endpoint. Versioned APIs are normally separate assets — /payments/v1 and /payments/v2 have different code, different findings and often different owners.

This matters for the forgotten-version problem: if the old version is not registered as an asset, nothing assesses it, and nothing reports that it is still reachable.

Working with API findings

  • Authorisation findings first. They are usually exploitable immediately, need no special access, and expose other customers' data.
  • Check whether a finding is systemic. One endpoint missing an authorisation check often means a whole class of endpoints shares the pattern. Fixing the pattern is worth more than fixing the instance.
  • Retest after fixing. Authorisation fixes are easy to get subtly wrong, and a fix that works for the tested case may not hold for adjacent ones.