Attackers as API testers: what Salt’s approach changes for security teams

At a glance

What this is: Salt argues that API probing can be treated as prioritised vulnerability intelligence because it reveals real attacker interest rather than a generic scan result.

Why it matters: For IAM and security teams, the lesson is that API exposure, authentication, and authorisation weaknesses should be triaged by observed attacker behaviour, not only by periodic testing output.

Context

APIs often fail in ways that traditional review cycles do not surface quickly enough. Broad scanning, code analysis, penetration tests, and bug bounty work all help, but they still leave teams deciding which findings matter most and which gaps are most likely to be exploited first.

The identity angle is real because API security is access security: attackers probing an API are testing authentication paths, authorisation decisions, and the trust boundaries around tokens and service access. When those controls are weak, the risk is not just a vulnerable endpoint but an abuse path into data and functions that should have been constrained.

Key questions

Q: What should security teams do first when APIs are already being probed by attackers?

A: Start by grouping the probed endpoints by business criticality and by the access control failure they suggest. Findings tied to authentication, object-level access, or privileged functions should move ahead of low-confidence scanner noise because they already reflect attacker interest and a plausible exploit path.

Q: Why does attacker-driven API probing create higher remediation priority?

A: Because it shows the weakness is not just possible, it is being actively tested in the wild. That means the exposure has crossed from theoretical risk into observed adversary interest, which is a stronger basis for prioritising fixes than a long list of unranked findings.

Q: What are the signs that an API authorization control is failing in practice?

A: Common warning signs include endpoints returning valid data without a token, access to records that should be scoped to another user, and responses that expose credentials or keys in configuration data. Another indicator is when iterating a parameter reveals large volumes of records in predictable increments. Those patterns suggest broken object or function level authorization, not just a minor configuration issue.

Q: How should teams compare API scanners and attacker-derived findings?

A: Use scanners to broaden coverage, but use attacker-derived findings to decide what gets fixed first. Scanners tell you what might be wrong, while live probing tells you what an attacker has already found worth exploiting, which is usually the better prioritisation signal.

Technical breakdown

Why API reconnaissance is different from broad vulnerability scanning

API reconnaissance is attacker-driven discovery. Instead of a scanner trying to enumerate known patterns, the adversary sends requests, studies responses, and infers business logic, hidden endpoints, parameter behaviour, and access control flaws. That means the signal is already filtered by attacker interest. If a probe reaches a sensitive function, the issue is not theoretical. It is a live control gap that an adversary has found worth exploring, which is why these findings often deserve higher operational priority than static lists of potential weaknesses.

Practical implication: treat observed probing as a prioritisation input, not just detection noise.

How attacker activity helps expose API authentication and authorisation gaps

The most valuable reconnaissance findings usually sit at the intersection of authentication, session handling, and authorisation. Attackers are testing whether tokens are accepted where they should not be, whether one object can be accessed through another account, and whether functions can be called outside intended roles. In identity terms, this is where broken trust around API credentials becomes visible. The issue is often not that an API exists, but that the API accepts a request without proving the caller should have that level of access.

Practical implication: validate token scope, object-level access, and function-level access against the behaviours attackers actually probe.

Why remediation quality matters more than finding volume

A long list of findings does not help if teams still have to translate each one into a fix. The article’s core operational claim is that attacker-derived insight can close that gap by stating where the weakness sits, what normal behaviour should look like, and how to remediate it. That changes the security workflow from broad discovery to targeted correction. In practice, the value is not just earlier detection. It is faster alignment between security and development on the exact control that failed.

Practical implication: route attacker-derived findings into engineering tickets that specify the broken control and the expected secure behaviour.

Threat narrative

Attacker objective: The attacker wants to find a reliable API path that yields unauthorised access to data or privileged functions with minimal friction.

1. Entry begins with reconnaissance against exposed APIs, where the attacker sends probes to map functions, parameters, and response patterns.
2. Credential or authorisation abuse follows when the attacker tests whether tokens, sessions, or object references grant more access than intended.
3. Impact occurs when the weakness is confirmed and the attacker can use the API path to reach data or functions that should have remained restricted.

Breaches seen in the wild

• Laravel-Lang Composer compromise 2026: A stolen GitHub PAT let an attacker rewrite every Laravel-Lang release tag in May 2026, serving a PHP stealer of cloud, CI and SSH credentials.
• United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API reconnaissance should be treated as live validation of trust boundaries, not just as hostile traffic. When an attacker is already exercising a function, the organisation has evidence that the exposure is operational, not hypothetical. That changes the governance model for API security because the question is no longer whether a weakness might exist, but whether an attacker has already found a path worth pursuing. Practitioners should prioritise controls around observed abuse patterns rather than waiting for periodic test cycles.

The most important API security gaps are often identity gaps in disguise. Authentication failures, broken object-level authorisation, and scope confusion all reflect a mismatch between caller identity and permitted action. This is where API security and IAM intersect most sharply: access decisions are being made at request time, but the trust model may still assume the caller is legitimate once a token exists. Teams should review API access as an identity governance problem, not only an application bug.

Observed attack interest is a better triage signal than raw vulnerability count. Broad scanning can surface many issues, but attacker-driven probing tells teams which weaknesses are likely to be exploited first and where the logic is easiest to abuse. That does not replace testing, but it does sharpen prioritisation and reduce remediation churn. The practical conclusion is to move high-risk API findings into the first fix queue when real adversary behaviour confirms them.

Salt's approach highlights prioritisation debt in API programmes. Many teams still depend on periodic scanning and manual testing to tell them where to act, even though those methods compete with time, budget, and coverage limits. Using attacker activity as a signal compresses the distance between discovery and remediation, which is valuable where APIs change quickly and business logic matters. Practitioners should use this to re-rank remediation by exploit interest, not just by scanner severity.

What this signals

API prioritisation debt is a governance problem, not just a tooling problem. When security teams rely on broad scanning alone, they often collect more findings than they can operationalise. The better control point is the point of observed attacker interest, because it tells teams which API weaknesses are most likely to be exploited next.

API security and IAM converge at the request boundary. If tokens, scopes, object references, and function permissions are not tightly aligned, attacker reconnaissance will expose the mismatch quickly. That makes API access review a live identity-control issue, not a periodic paperwork exercise.

For practitioners

• Prioritise APIs under active reconnaissance Feed repeated probing, unusual parameter variation, and function enumeration into remediation triage so teams fix what attackers are already testing first.
• Map API findings to identity and authorisation controls Review whether each high-risk finding is caused by broken object-level authorisation, weak token scope, or an over-permissive function path rather than treating it as a generic bug.
• Convert attacker-derived insight into engineering tickets Document the expected secure behaviour, the observed deviation, and the exact endpoint or function that needs correction so developers can act without re-investigation.
• Use probing patterns to rank remediation backlog Promote findings that show live attacker interest above low-confidence issues from broad scans or unvalidated testing, especially where sensitive data or privileged actions are exposed.

Key takeaways

• API reconnaissance can be a stronger prioritisation signal than broad vulnerability discovery because it reflects real attacker interest in specific functions and access paths.
• The central weakness is often not an API’s existence but the way identity, token scope, and authorisation are enforced at request time.
• Teams should route attacker-derived findings into the first remediation queue when probes reveal exposed business logic, weak access checks, or over-permissive API behaviour.

Key terms

• API Reconnaissance: API reconnaissance is the phase where an attacker maps exposed endpoints, parameters, error responses, and trust behaviour to learn how the application works. It often reveals logic flaws and access control weaknesses that do not show up in static scans alone.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Broken Function Level Authorization: A failure where an API allows a caller to invoke a function reserved for a more privileged role. The problem appears when the API checks whether a user is logged in but not whether they are allowed to perform that action. It is a privilege boundary failure at the application control layer.
• Request-boundary access control: Request-boundary access control is the discipline of evaluating identity, scope, and permission at the exact moment an API call is made. It matters because a valid token or session is not enough on its own if the request can still reach a function or object outside the caller's authority.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps practitioners connect identity controls to the broader security programme they run every day.