Notifications
Clear all
Topic starter
20/08/2026 5:21 pm
TL;DR: A public FIA API flaw exposed passport scans and personal data for hundreds of drivers because object-level authorization failed, according to Equixly’s analysis of the incident and the underlying testing gap. The case shows that manual API testing alone cannot keep pace with API change, and continuous validation is now a governance requirement, not a nice-to-have.
NHIMG editorial — based on content published by Equixly covering the Formula 1 FIA API vulnerability: lessons from continuous API security testing
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Equixly's analysis of the Formula 1 FIA API vulnerability and testing gap →
Formula 1 API exposure: what it means for API security teams?
Explore further
20/08/2026 6:12 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Formula 1 API exposure shows why access control must be tested continuously
