API security fails when authentication and authorization go granular

At a glance

What this is: This is an analysis of why modern API security controls struggle against attackers who exploit application-specific logic and low-noise abuse patterns.

Why it matters: It matters because IAM, PAM, and broader security teams need to govern API access, authorisation, and monitoring as part of the same control plane, especially where APIs expose sensitive data and connect trusted systems.

By the numbers:

• That fine could reach $1.63B GDPR fine for Facebook.

👉 Read Salt's analysis of API security strategy and modern attack paths

Context

API security is not just about stopping obvious exploits. As applications become more API-driven, attackers can abuse legitimate access, logic flaws, and weak authorisation decisions in ways that traditional perimeter tools often miss. For identity and access teams, the core issue is that API access can be technically authenticated while still being functionally unsafe.

This makes API security a governance problem as well as a tooling problem. When APIs connect customer applications, partners, and microservices, the control challenge shifts to understanding which identities can call which functions, what normal behaviour looks like, and how to detect abuse without breaking business logic.

Key questions

Q: What breaks when API authentication is correct but authorisation is weak?

A: Attackers can still read or modify data they should not reach, because identity was proven without proving entitlement. That failure usually appears as BOLA, broken function-level access, or mass assignment. Security teams should test whether an authenticated caller can move from one object, record, or action to another without additional approval.

Q: Why do APIs create identity governance risk across machine and human access?

A: APIs often carry the real access decision for service accounts, tokens, and human sessions. If an API accepts the wrong identity context, broadens scope during errors, or leaks data in failure paths, the governance model is broken even when the application appears to work.

Q: How do security teams know if API authorisation is actually working?

A: They should test whether each identity can only complete the specific actions it is supposed to perform, then compare that result with runtime logs and anomaly patterns. If valid credentials can still retrieve excessive data, call restricted methods, or chain privileged actions, the policy is not holding.

Q: Who is accountable when a public API leaks data through valid access?

A: Accountability usually spans application owners, IAM or platform teams, and security leadership, because the failure is shared between access design, endpoint logic, and monitoring. In regulated environments, the organisation must also be able to show that access controls and logging were proportionate to the sensitivity of the data involved.

Technical breakdown

Why signature-based tools miss API abuse

Web application firewalls and RASP tools work best when they can match known bad patterns. APIs are different because each endpoint has its own schema, business logic, and authorisation rules, so the abuse often looks like a valid request rather than a classic exploit. Attackers increasingly probe for edge-case behaviour, over-permissive endpoints, and inconsistencies between intended and actual access paths. The result is that detection has to understand the API itself, not just the payload. Practical implication: teams need API-aware runtime visibility, not only generic web filtering.

Practical implication: move from pattern matching to API-specific behavioural and authorisation controls.

Authentication without tight authorisation still leaves exposure

Authentication proves an identity exists, but it does not prove that identity should be able to do everything the API allows. Public and developer-facing APIs often make credential acquisition too easy, and once an attacker has valid credentials, the real risk becomes what they can call, retrieve, or change. Fine-grained authorisation is therefore the control that separates safe access from dangerous access, but in practice it is hard to maintain because API logic changes quickly and permissions are often entangled across roles and services. Practical implication: entitlements must be tested continuously against actual API actions.

Practical implication: validate authorisation at the endpoint and action level, not just at login.

Why rate limiting and shift-left controls are not enough

Rate limiting can slow volume-based abuse, but many API attacks are low-and-slow and designed to look like normal use. Shift-left measures such as code scanning and penetration testing help, but they can miss live abuse paths, generate noisy results, or leave parts of the API surface untested. That means security teams need both pre-deployment assurance and runtime detection, especially where a single request can cause data exposure or service disruption. Practical implication: combine testing, monitoring, and prioritised remediation rather than relying on one layer.

Practical implication: pair pre-production testing with runtime controls that detect low-volume abuse.

Threat narrative

Attacker objective: The attacker wants to use valid API access to steal sensitive data, disrupt service, or both, while staying below the threshold of conventional detection.

1. Entry occurs when an attacker acquires legitimate API credentials through public signup, phishing, or another low-friction account creation path.
2. Escalation follows when the attacker uses valid access to probe business logic, over-permissive endpoints, or weak authorisation checks that expose data or functions beyond intended scope.
3. Impact occurs when the attacker triggers denial of service or exfiltrates sensitive personal data through requests that look legitimate to traditional controls.

NHI Mgmt Group analysis

API security has become an identity governance problem, not just a web protection problem. The article shows that attackers are not only looking for code flaws, they are looking for usable identities and permissions that let them operate through valid API calls. That is why API authorisation now sits alongside IAM governance, because the question is not simply whether a request is authenticated, but whether the calling identity should be trusted for that action. Practitioners should treat API entitlements as governed access, not as implementation detail.

Granular authorisation is the real control boundary in modern API estates. Authentication can be bypassed by credential theft, account creation, or social engineering, but authorisation decides the blast radius. In API-heavy environments, over-broad roles and inconsistent policy logic create silent exposure that traditional tools do not see until abuse is already underway. The practical conclusion is that authorisation policy must be tested against real request paths and business actions, not just reviewed on paper.

Low-noise abuse is now the dominant API risk pattern. The important shift here is from noisy exploit traffic to legitimate-looking calls that exploit trust in the application layer. That creates a detection gap for teams that still assume attack activity will be obvious or volumetric. API trust gap: the mismatch between authenticated access and authorised intent is now the core failure mode, and it demands API-specific runtime governance.

Shift-left controls reduce exposure, but they do not replace runtime decisioning. Code scanning and penetration testing can find defects before release, yet the article correctly notes that they are uneven in coverage and can miss live exploitation behaviour. This is where broader security governance matters: development, appsec, IAM, and SOC teams need shared ownership of API risk rather than isolated tooling decisions. Practitioners should align prevention and detection around the same access model.

API-driven architectures force security teams to think in terms of function-level privilege. When APIs connect customers, partners, and microservices, a single identity may be able to reach multiple business functions that were never designed as a coherent privilege set. That is a classic sprawl problem in a different form, and it is why least privilege has to be expressed at the action level. The field should expect more emphasis on continuous authorisation and behavioural baselines for APIs.

What this signals

API-heavy estates are pushing security teams toward continuous authorisation thinking, because static access reviews do not explain what a caller can do at runtime. When a valid identity can still cause data exposure or disruption, the control question changes from who has access to what to which action is the identity actually permitted to take. That is the same governance shift visible in third-party OAuth visibility gaps, where access exists long before it is truly understood.

Access-path governance: the practical next step is to treat endpoints, methods, and workflows as privileged surfaces that need monitoring as much as admin consoles do. Teams that already manage secrets, service accounts, and partner integrations can reuse those governance patterns for APIs, especially where machine-to-machine access exposes sensitive data. For control design, the NIST SP 800-53 Rev 5 Security and Privacy Controls catalog remains useful for aligning access control and audit requirements.

As API estates expand, the boundary between application security and identity governance keeps narrowing. Organisations that only measure login success or WAF coverage will miss the real risk, which is whether authenticated identities can abuse business logic without tripping controls. That is why API runtime monitoring, least privilege, and entitlement review need to sit in the same programme conversation.

For practitioners

• Inventory API identities and entitlements Map which users, service accounts, and partner integrations can call each sensitive API action. Treat each endpoint and method as a distinct access decision so that over-broad permissions become visible before attackers find them.
• Test authorisation against real business actions Validate whether authenticated identities can only perform the actions they are meant to perform, especially in chained workflows and microservices. Focus tests on the requests that return data, mutate records, or trigger downstream processes.
• Deploy API behavioural monitoring Baseline normal request patterns and alert on deviations such as unusual data access sequences, low-and-slow enumeration, or repeated probing of edge-case logic. This is the layer that catches abuse that looks legitimate to signature-based tools.
• Prioritise runtime controls for exposed APIs Use runtime protection where the API surface is public, partner-facing, or high-value, and pair it with targeted remediation of the endpoints most likely to leak data or enable outage conditions. Keep testing and monitoring linked so findings are not left in isolation.

Key takeaways

• APIs now fail at the boundary between authentication and authorisation, where valid access can still be unsafe.
• Traditional signature-based controls miss low-noise API abuse because the attacker uses legitimate-looking requests, not obvious exploits.
• The control priority is shifting toward function-level privilege, runtime behavioural monitoring, and continuous testing of real API actions.

Key terms

• API authorisation: API authorisation is the decision logic that determines what an authenticated identity can do through an interface. It is stronger than simple login control because it governs actions, data access, and delegated requests at every service boundary.
• Runtime API Monitoring: Runtime API monitoring inspects API traffic and behaviour while the service is live, rather than only during scheduled scans. It looks for abuse patterns, abnormal request sequences, and misused credentials, making it especially useful where machine-to-machine access changes faster than review cycles.
• Process-level Privilege: Process-level privilege means granting access to a specific task or workflow rather than to the whole system or platform. It reduces blast radius by limiting what the process can do, when it can do it and how long the entitlement remains valid.
• Low-Noise Abuse: Low-noise abuse is malicious activity designed to blend into ordinary traffic and avoid threshold-based alerts. For APIs, it often means a small number of carefully crafted requests that exploit logic flaws, over-permissioned endpoints, or data-return behaviours.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• Examples of how attackers use valid credentials to probe APIs without triggering obvious alarms.
• Practical discussion of how authentication, authorisation, rate limiting, and shift-left measures fit together in an API stack.
• Specific commentary on why nuanced API behaviour is difficult for traditional WAF and RASP tools to interpret.
• The source article's threat framing around data exfiltration and denial-of-service scenarios in API-heavy environments.

👉 Salt's full post covers the authentication, authorisation, and runtime monitoring gaps in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to connect access control to real-world governance. It supports security and identity teams building stronger programmes across human and non-human identity.