Formula 1 API exposure shows why access control must be tested continuously

At a glance

What this is: This is an independent analysis of a Formula 1 API exposure that stemmed from broken object-level authorization and excessive data exposure in a public-facing portal.

Why it matters: It matters because API access control failures can expose highly sensitive data even in well-resourced environments, and IAM teams increasingly need to govern application authorization paths as part of identity and access control.

By the numbers:

• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read Equixly's analysis of the Formula 1 FIA API vulnerability and testing gap

Context

APIs often fail at the authorization layer, not the network layer. When an application accepts an identifier and does not verify whether the caller is allowed to access that object, the result is broken object level authorization, or IDOR in practical terms. That creates a direct path from a small logic flaw to large-scale data exposure, which is why API security and identity governance now intersect more often than many programmes assume.

The Formula 1 incident is a useful reminder that access control is an application responsibility as much as an IAM responsibility. Where APIs expose sensitive records, identity-aware testing needs to verify object ownership, entitlement boundaries, and data minimisation. That makes the issue relevant to IAM, PAM, and NHI teams wherever service-to-service access or delegated application access is involved.

This starting position is typical of modern API risk: the flaw was simple, the blast radius was large, and the failure mode was preventable with continuous testing rather than one-off review.

Key questions

Q: What breaks when GraphQL APIs do not enforce object-level authorization?

A: The application can authenticate a user and still allow that user to access or change records they do not own. In GraphQL, one mutation may touch several objects, so missing checks at any layer can expose data, enable cross-account actions, or allow fraudulent transactions. The fix is server-side entitlement validation on every sensitive object, not just at login.

Q: Why do APIs create identity risk even when the application code is secure?

A: APIs create identity risk because the code can be clean while the credentials behind it remain exposed, over-privileged, or reused. Attackers usually target the secret, not the endpoint. Once they have a valid key or token, they can impersonate the workload and inherit whatever access that identity already has.

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: How should teams govern APIs that are used by service accounts and automation?

A: Treat those API paths as part of the identity estate. Inventory the service accounts, tokens, and delegated applications that can reach sensitive endpoints, apply least privilege to each one, and retest whenever a workflow or payload changes. That prevents machine identities from inheriting broad access by default.

Technical breakdown

How broken object level authorization turns a valid request into a data leak

Broken object level authorization happens when an API checks that a caller is authenticated, but not whether the caller is allowed to access the specific object requested. In IDOR patterns, the attacker changes a driver ID, account ID, or record key and receives another user’s data. Excessive data exposure makes the problem worse because the response contains more sensitive fields than the workflow actually needs. These flaws are often missed when teams test only happy paths or rely on endpoint coverage without permission-state validation.

Practical implication: test object access rules, not just endpoint reachability, before release.

Why manual API testing misses privilege and parameter edge cases

Manual penetration testing is effective because it can reason about business logic, but it is inherently time-boxed. Security testers cannot enumerate every endpoint, parameter combination, or role state across a changing application estate. That leaves gaps between testing cycles, especially when developers add new routes or modify authorization logic. Continuous validation closes that gap by re-running access-control checks whenever code changes, rather than waiting for an annual review or a compliance window.

Practical implication: move authorization regression tests into CI/CD so new logic is checked immediately.

Why API security is becoming an identity governance problem

APIs increasingly mediate access on behalf of users, workloads, and automated services, so an authorization failure is also a governance failure. The control question is not only whether the caller is trusted, but whether the application enforces least privilege at the object and field level. That is especially relevant where service accounts, delegated tokens, or AI-driven agents call APIs at machine speed. In those environments, traditional perimeter checks do not constrain what a valid identity can overreach.

Practical implication: treat API authorization paths as part of identity governance and least-privilege design.

Threat narrative

Attacker objective: The objective is to retrieve protected records at scale by abusing weak object-level authorization rather than breaking authentication itself.

1. Entry occurred through a public-facing API that accepted an object identifier without adequately checking permission to that record.
2. Escalation happened when sequential IDs or similar parameters let the requester access data belonging to other users.
3. Impact was sensitive personal data exposure, including passport scans and contact information, which could support fraud or privacy abuse.

NHI Mgmt Group analysis

Broken object-level authorization is an access-control failure, not a tooling failure. The core weakness in incidents like this is that the API recognises the caller but does not enforce entitlement at the object boundary. That means the control plane is present, but the decision logic is missing where it matters. For API-heavy environments, that shifts the governance burden toward application-layer authorization testing and entitlement design.

Continuous validation is the only realistic answer to API change velocity. One-off testing assumes the attack surface is stable long enough for periodic review to remain meaningful. In modern delivery pipelines, that assumption fails because small code changes can alter authorization outcomes in ways static reviews miss. Teams should treat authorization regression as a standing control, aligned to NIST Cybersecurity Framework 2.0 and the relevant access-control expectations in NIST SP 800-53 Rev 5.

API security now overlaps with NHI governance whenever machine identities call business data APIs. Workload tokens, service accounts, and delegated app identities can all exercise the same API paths that human users do, often with broader reach and less scrutiny. That creates a governance gap if organisations only review human access while leaving machine-to-API permissions under-tested. Practitioners should frame API authorization as part of the identity estate, not a separate application-only problem.

Continuous API testing is becoming a named control pattern for modern identity risk. The useful concept here is authorization regression debt: the gap that accumulates when each release can reintroduce broken access checks faster than periodic testing can detect them. That debt grows fastest in systems that expose regulated or highly sensitive data. Teams that measure only release volume, not authorization drift, will understate the real exposure.

What this signals

Authorization drift is becoming a programme-level exposure, not just an application defect. If API teams are not continuously testing object-level access, identity programmes will inherit blind spots that traditional access reviews do not see. The practical response is to align API regression testing with identity lifecycle controls and entitlement monitoring, using guidance such as the NIST Cybersecurity Framework 2.0 where access control and detection need to work together.

API security teams should expect more machine-driven access paths, not fewer. As service accounts and automated workflows increase, the number of identities capable of reaching data APIs will grow faster than manual review can handle. That is where concepts like authorization regression debt: the backlog of untested permission changes that accumulates between releases, become operationally useful. The governance lesson is to catch drift before it turns into sensitive-data exposure.

The control priority is moving from periodic assurance to continuous proof. In practice, that means pairing application-layer tests with identity inventory, service-account review, and stronger data minimisation for regulated fields.

For practitioners

• Test object ownership on every sensitive API path Add negative tests that verify a caller cannot read, update, or enumerate records outside its entitlement boundary, especially where IDs are guessable or sequential.
• Put authorization checks into CI/CD regression suites Run access-control tests automatically on each build so broken object-level authorization is detected during development, not after deployment.
• Minimise response fields by default Return only the fields needed for the specific workflow, then separate high-risk attributes such as passport data, identity documents, and contact details into stricter access paths.
• Review API permissions for workload identities Map which service accounts, tokens, and delegated app identities can call regulated data APIs, then remove standing access that exceeds the business task.

Key takeaways

• This incident shows that authentication alone is not enough when an API fails to verify object ownership.
• The exposure was preventable because the root problem was permission logic, not sophisticated exploitation.
• Continuous authorization testing and tighter identity-aware API governance are the controls that reduce this class of failure.

Key terms

• 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.
• Excessive Data Exposure: Excessive data exposure occurs when an API returns more information than the caller actually needs. The issue is usually a design and authorization problem rather than a coding typo, and it increases breach impact because a stolen credential can reveal far more data than intended.
• Authorization Regression Debt: The accumulation of untested permission changes across releases, feature flags, and new endpoints. When teams validate APIs only periodically, each code change can widen the gap between intended access policy and actual runtime behaviour, leaving hidden exposure until production or a breach test finds it.
• Abuse-Aware API Testing: Abuse-aware API testing evaluates whether a system remains safe when ordinary features are used at scale, across many identities, and in ways that reconstruct hidden value. It focuses on traversal, aggregation, enumerability, and economic extractability. The goal is to identify unsafe behaviour before attackers do.

What's in the full article

Equixly's full blog research covers the operational detail this post intentionally leaves for the source:

• Dynamic API discovery methods for uncovering undocumented endpoints and parameters
• Access-control regression examples that show how unauthorized object access is tested in practice
• CI/CD integration detail for continuous validation across release cycles
• Operational guidance on using AI-assisted agents to scale API testing beyond manual review

👉 The full Equixly post covers the access-control testing approach, developer workflow integration, and remediation framing.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management through practitioner-focused instruction. It is designed for security teams that need to connect identity controls to real operational risk across modern environments.